web-dev-qa-db-ja.com

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

devtmpfsとtmpfsについて2の質問があります：
（1）

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パーティションの共有スペースではなく、専用のメモリスペースがありますか？

linuxfilesystemslinux-kerneldevicestmpfs
5
Nan Xiao

すべてのtmpfsマウントで、「Avail」は人為的な制限です。 tmpfsマウントのデフォルトサイズは、RAMの半分です。マウント時に調整できます。 （_man mount_、tmpfsまでスクロール）。

マウントは同じスペースを共有しません。つまり、_/dev/shm_マウントを埋めた場合、_/dev_は「使用済み」を表示しなくなり、必ずしもデータを_/dev_

（誰かが単一のtmpfsからバインドマウントすることでスペースを共有するtmpfsマウントを考案することができます。しかし、それはこれらのマウントのいずれかがデフォルトで設定される方法ではありません）。

どちらもシステムメモリに支えられているため、同じスペースを共有します。 _/dev/shm_と_/dev_の両方を埋めようとした場合、物理RAMと同じスペースが割り当てられます。スワップ領域があると仮定すると、これは完全に可能です。しかし、それは一般に良い考えではなく、不十分に終わります。

これは、ユーザーがアクセスできる複数のtmpfsマウントを用意するという考えにはあまり合いません。つまり_/dev/shm_ + _/tmp_多くのシステムで。間違いなくwould 2つの大きなマウントが同じスペースを共有している場合はより良いです。 （Posix SHMは、文字通り、ユーザーがアクセス可能なtmpfsでファイルを開くためのインターフェースです）。

_/dev/_、_/run_、_/sys/fs/cgroups_はシステムディレクトリです。それらは小さく、かなりのデータには使用しないでください。したがって、問題は発生しません。 Debian（8）は、制限を設定するのに少し優れているようです。 500MBシステムでは、10、100、250 MB、および_/run/lock_の場合はそれぞれ5つに制限されています。

_/run_は私のシステムで約2MB使用しています。 systemd-journalはそのかなりの部分を占めており、デフォルトでは「Avail」の10％まで増える可能性があります。 （RuntimeMaxUseオプション）、これは私のモデルに適合しません。

あなたがそこに50MBを持っているのはそれが理由だと私は思うでしょう。物理的な5％に相当するRAMログファイルの場合...個人的にはそれ自体は大きな問題ではありませんが、それはきれいではなく、間違い/見落としと呼んでいます。キャップがその2MBマークと同じオーダーに設定されている場合は、さらに良くなります。

現時点では、1,000の肥大化による死を防止したい場合は、_/run_のサイズをすべてのシステムに対して手動で設定する必要があることを示唆しています。 2％（私のDebianの例から）でさえ、ありきたりなようです。

7
sourcejedi

各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

これにより、tmpfsの3つのインスタンスが作成されます。デフォルトでは、それぞれ50％のメモリ制限があるため、合計で150％になります（スワップを考慮しない場合は、スワップを自由に追加できます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 #
2
frostschutz

（1）tmpfsに基づくすべてのファイルシステムは、OSの利用可能な仮想メモリをバックエンドとして共有しています。 devtmpfsはたまたま同じスペースを使用しますが、前者とは異なり、データが含まれていないため、大きくなることはありません。

（2）/run/usersサブディレクトリはsystemdによって個人的な一時的なものとして作成されます/tmpディレクトリ。また、他のすべてのtmpfsベースのファイルシステムと同じ仮想メモリ空​​間を共有します。彼らが小さく見えるのは、このディレクトリを埋めることにより、1人のユーザーが他のすべてのユーザーに影響を与えるのを防ぐために設定されたキャッピングが原因です。

1
jlliagre