☰

tmpfs 和 devtmpfs 共享相同的内存区域吗？

tag-icon • tag-icon linux filesystems linux-kernel devices tmpfs
tmpfs 和 devtmpfs 共享相同的内存区域吗？

我的系统盘使用情况是这样的：

# df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root   50G   39G   12G  77% /
devtmpfs               5.8G     0  5.8G   0% /dev
tmpfs                  5.8G  240K  5.8G   1% /dev/shm
tmpfs                  5.8G   50M  5.8G   1% /run
tmpfs                  5.8G     0  5.8G   0% /sys/fs/cgroup
/dev/mapper/rhel-home  1.3T  5.4G  1.3T   1% /home
/dev/sda2              497M  212M  285M  43% /boot
/dev/sda1              200M  9.5M  191M   5% /boot/efi
tmpfs                  1.2G   16K  1.2G   1% /run/user/1200
tmpfs                  1.2G   16K  1.2G   1% /run/user/1000
tmpfs                  1.2G     0  1.2G   0% /run/user/0

我对和有2疑问： (1) devtmpfstmpfs

devtmpfs               5.8G     0  5.8G   0% /dev
tmpfs                  5.8G  240K  5.8G   1% /dev/shm
tmpfs                  5.8G   50M  5.8G   1% /run
tmpfs                  5.8G     0  5.8G   0% /sys/fs/cgroup

以上所有空间都是5.8G，它们共享相同的内存空间吗？

(2)

tmpfs                  1.2G   16K  1.2G   1% /run/user/1200
tmpfs                  1.2G   16K  1.2G   1% /run/user/1000
tmpfs                  1.2G     0  1.2G   0% /run/user/0

每个用户是否都有自己的专用内存空间，而不是/run/user分区中的共享空间？

答案1

对于所有 tmpfs 挂载，“Avail”是人为限制。 tmpfs 安装的默认大小是 RAM 的一半。它可以在安装时调整。 ( man mount，滚动至tmpfs)。

安装不共享相同的空间，因为如果您填充了安装/dev/shm，/dev将不会再显示“已使用”，并且不一定会阻止您将数据写入/dev

（有人可以tmpfs通过从单个 tmpfs 绑定安装来设计共享空间的安装。但这不是默认设置任何安装的方式）。

它们确实共享相同的空间，因为它们都由系统内存支持。如果您尝试同时填充/dev/shm和/dev，您将分配等于物理 RAM 的空间。假设您有交换空间，这是完全可能的。然而，这通常不是一个好主意，并且最终会很糟糕。

这与拥有多个用户可访问的 tmpfs 挂载的想法不太相符。在许多系统上即/dev/shm+ 。/tmp可以说会如果两个大安装共享相同的空间会更好。 （Posix SHM 实际上是一个在用户可访问的 tmpfs 上打开文件的接口）。

/dev/、/run、/sys/fs/cgroups是系统目录。它们应该很小，不用于存储大量数据，因此不会引起问题。 Debian (8) 似乎更擅长为它们设置限制；在 500MB 的系统上，我发现它们分别限制为 10、100、250 MB 和另外 5 个/run/lock。

/run我的系统上使用了大约 2MB。 systemd-journal 是其中的重要组成部分，默认情况下可能会增长到“Avail”的 10%。 （RuntimeMaxUse选项），这不适合我的模型。

我敢打赌这就是你有 50MB 的原因。允许相当于 5% 的物理 RAM 用于日志文件...就个人而言，这本身并不是一个大问题，但它并不漂亮，我称之为错误/疏忽。如果将上限设置为与 2MB 标记相同的顺序，那就更好了。

目前，/run如果您想防止因膨胀而死亡，则建议应为每个系统手动设置 的大小。即使是 2%（来自我的 Debian 示例）也显得很自以为是。

答案2

每个tmpfs实例都是独立的，因此可能会过度分配内存，如果您用大文件填满整个内存tmpfs，系统最终将由于没有更多可用内存而停止，并且无法释放任何内存（不删除tmpfs文件或卸载它）。

tmpfs可以使用交换分区来换出数据，但如果您正在主动读取/写入这些文件，此时必须将其换回，那么即使这样也无济于事。

基本上，具有大量tmpfs已安装实例的系统通常在这样的假设下运行：虽然tmpfs存在，但实际上不会被填充到极限。

如果你想尝试这个 - 最好是在没有安装任何东西的 Live CD 上 - 那么它的工作原理如下：

mkdir a b c
mount -t tmpfs tmpfs a
mount -t tmpfs tmpfs b
mount -t tmpfs tmpfs c
truncate -s 1T a/a b/b c/c
shred -v -n 1 a/a b/b c/c

这将创建 3 个实例tmpfs，默认情况下每个实例都有 50% 的内存限制，因此总共为 150%（不包括 swap，如果您确实有 swap，请随意添加d e f ...）。

的输出shred将如下所示：

shred: a/a: pass 1/1 (random)...
shred: a/a: error writing at offset 1049104384: No space left on device
shred: b/b: pass 1/1 (random)...
# system hangs indefinitely at this point, without swap it never reaches c/c #

答案3

(1) 所有基于的文件系统tmpfs都共享操作系统可用的虚拟内存作为后端。devtmpfs碰巧使用相同的空间，但与前者不同，它不包含数据，因此不应增长。

(2)/run/users子目录由 systemd 创建为个人的、临时的/tmp目录。它们还与所有其他tmpfs基于文件系统共享相同的虚拟内存空间。它们看起来较小的事实是由于设置了上限，以防止单个用户通过填充此目录来影响所有其他用户。

相关内容