☰

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

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

マウントを埋めると、「使用済み」と表示されなくなり、必ずしもデータの書き込みを妨げないため、マウントは同じスペースを共有しませ/dev/shmん/dev。/dev

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

どちらもシステムメモリとしてサポートされているため、同じスペースを共有します。/dev/shmとすべてを埋めようとすると、/dev物理RAMと同じスペースが割り当てられます。スワップスペースがあると仮定すると、これは完全に可能です。しかし、これは一般的に良い考えではなく、最終的に悪い結果をもたらします。

これは、複数のユーザーがアクセスできるtmpfsマウントを持つという考えには適していません。多くのシステムでは+です/dev/shm。/tmpと言える会議2つの大規模なインストゥルメントが同じスペースを共有する場合は、より良いでしょう。 （Posix SHMは、実際にユーザーがアクセスできるtmpfsでファイルを開くためのインターフェースです。）

/dev/、/runは/sys/fs/cgroupsシステムディレクトリです。サイズが小さく、大量のデータを保存するために使用されていないため、問題は発生しません。 Debian(8) は、500 MB システムで制限を設定する方が良いようです。 10、100、250MBと5に制限されています/run/lock。

/run私のシステムでは、約2MBが使用されます。 systemd-journalはこれの大部分を占めており、基本的に「Avail」の10％まで増やすことができます。 （RuntimeMaxUseオプション）、私のモデルに合わない。

だから50MBがあると思います。物理RAMの5％に相当するログファイルの使用を許可します...個人的にはそれ自体は大きな問題ではありませんが、きれいではなく、バグ/欠落と呼びたいと思います。 2MB表示と同じ順序でキャップを設定すると良いと思います。

現時点では、/run膨張による死亡を防ぐために、システムごとに手動でサイズを設定することをお勧めします。 （私のDebianの例では）2％でさえも非常にテーマを超えているようです。

おすすめ記事