非常に多数の空のファイルを作成することにより、ディスク領域を使い果たすことはできますか？

空のテキストファイルのバイト数がゼロであることはよく知られています。

しかし、それぞれにはメタデータが含まれており、私の調査によれば、 iノードに、スペースを使用します。

これを考えると、空のテキストファイルを純粋に作成することでディスクをいっぱいにすることは可能だと私には思えます。これは正しいです？その場合、たとえば1GBのディスクに何個の空のテキストファイルを書き込む必要がありますか？

いくつかのチェックを行うために実行しましたdf -iが、これは明らかに、使用されているiノードの割合（？）を示しています。

Filesystem             Inodes  IUsed    IFree IUse% Mounted on
udev                   947470    556   946914    1% /dev
tmpfs                  952593    805   951788    1% /run
/dev/sda2            28786688 667980 28118708    3% /
tmpfs                  952593     25   952568    1% /dev/shm
tmpfs                  952593      5   952588    1% /run/lock
tmpfs                  952593     16   952577    1% /sys/fs/cgroup
/dev/sda1                   0      0        0     - /boot/efi
tmpfs                  952593     25   952568    1% /run/user/1000
/home/lucho/.Private 28786688 667980 28118708    3% /home/lucho

この出力は、28786688iノード全体を示唆しています。その後、ルートファイルシステム（デバイス/dev/sda2）にファイルを作成する次の試みが返されますENOSPC（「デバイスにスペースがありません」）。

説明：元の* nixファイルシステム設計では、ファイルシステムの作成時にiノードの最大数が設定されます。専用のスペースがそれらに割り当てられます。データ用のスペースがなくなる前にiノードを使い果たすか、その逆も可能です。最も一般的なデフォルトのLinuxファイルシステムには、ext4まだこの制限があります。ext4のiノードサイズについては、mkfs.ext4のマンページを参照してください。

Linuxは、この制限なしで他のファイルシステムをサポートします。でbtrfs、スペースが動的に割り当てられます。「iノード構造は比較的小さく、埋め込みファイルデータや拡張属性データは含まれません。」（ext3 / 4は、拡張属性用にiノード内にいくつかのスペースを割り当てます）。もちろん、メタデータ/ディレクトリエントリを作成しすぎると、ディスク領域が不足する可能性があります。

それについて考えると、tmpfsはiノードが動的に割り当てられる別の例です。df -iこれらのファイルシステムで実際に報告されるiノードの最大数が実際に何を意味するかを知ることは困難です。表示されている値に意味を付けません。

「XFSはiノードも動的に割り当てます。JFSもそうです。reiserfsも行いました。F2FSも同様です。従来のUnixファイルシステムはmkfs時にiノードを静的に割り当てます。例外ではなく、ルール。

「ところで、XFSでは、iノードが使用するスペースの最大パーセンテージに制限を設定できるため、既存のファイルに追加できないポイントに到達する前に、iノードが不足する可能性があります（FSのデフォルトは25％です。 1TBの下で、ファイルシステムの5％アップ50TB、それよりも大きな1％に）とにかく、メタデータ（i-ノードとエクステント・マップ）に、この領域の使用量は、通常に反映されます。df -h」 - ピーター・コルドこの回答へのコメントで

空のファイルを作成するには、次を使用する必要があります。

• iノード、ファイルごとに1つ。
• 追加のディレクトリエントリもファイルごとに1つですが、集約されます。

使用可能なiノードの数は、ファイルシステムの作成時に決定されることが多く、変更することはできません（BtrfsやXFSなどの一部のファイルシステムは、iノードを動的に割り当てます）。それがによって測定されるものdf -iです。iノードが不足すると、使用可能なディスク容量がある場合でも、新しいファイルやディレクトリを作成できません。

ディレクトリエントリも、使用可能なディスク領域から領域を占有します。これを確認するには、ディレクトリのサイズを確認します。これは常にブロックサイズの倍数であり、ディレクトリに多数のファイルが含まれる場合、そのサイズは大きくなります。ディスク容量が不足すると、使用可能なiノードがある場合でも、「満杯」のディレクトリ（つまり、新しいファイルを追加すると新しいブロックを割り当てる必要があるディレクトリ）に新しいファイルまたはディレクトリを作成できない場合があります。

そのため、空のファイルのみを使用してディスク領域が不足する可能性があります。

純粋な論理引数：

ファイル名は、ゼロ以外のバイト数で構成されます。絶対的な最大量のファイル名を許可するように設計された仮想ファイルシステムでの理論上の最大圧縮を使用しても、各ファイル名は物理ディスクのどこかで少なくとも1ビットを消費します。おそらくそれ以上ですが、「ファイルごとに1ビット」が簡単な最小値です。

プラッターに収まる可能性のあるビットの量を計算します。これは、その上に格納できる（空または空でない）ファイルの理論上の最大数です。

したがって、答えはイエスです。最終的には、空のファイルを追加し続けると、使用しているストレージに関係なく、スペースが不足します。明らかに、この方法で計算された最大値よりはるかに早く実行されますが、実行されます。

単純にいいえ。ただし、Linux上のiノードを使い果たすことはできますが、これはスペースがなくなることと同じです。

あなたのシェルでこのようなものを試すことができます n=0; while :; do touch $n; let n=n+1; done

必ず仮想マシンで実行してください。そうしないと、iノードが非常に早くなくなります。

空のファイルを作成してディスクをいっぱいにすることはできません。ディスクには新しいファイル用に十分なスペースがあります。しかし、はい、ファイルシステムの空きiノードの有限な供給を使い果たすことができます-その時点で、新しいファイルを作成することはできません（ディスクは-使用されているスペースが行く限り-事実上空です）。ディスクではなく、すべて使用されているのはファイルシステムのiノードのリストだけです。したがって、ファイルシステムはいっぱいですが、ディスクは実質的に空です。iノードテーブルはディスク上のスペースを使用しますが、ファイルを追加してもテーブルは拡大しません。紙の行に書き込むときに用紙が拡大しないように。

（Baard Kopperudによるコメントへの回答）