空のテキストファイルのバイト数がゼロであることはよく知られています。
ただし、それらのそれぞれには metadata が含まれています。私の研究によれば、これは inodes に格納され、スペースを使用します。
これを考えると、純粋に空のテキストファイルを作成することでディスクをいっぱいにすることは可能であると私には論理的に思えます。これは正しいです?もしそうなら、たとえば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
この出力は、全体的に28786688
iノードを示唆しています。その後、ルートファイルシステム(デバイス/dev/sda2
)にファイルを作成しようとすると、ENOSPC
(「デバイスにスペースがありません」)が返されます。
説明:オリジナルの* nixファイルシステム設計では、ファイルシステムの作成時にiノードの最大数が設定されています。専用スペースが割り当てられています。データ用のスペースが不足する前にiノードが不足するか、またはその逆が可能です。最も一般的なデフォルトのLinuxファイルシステムext4
には、まだこの制限があります。 ext4のiノードサイズについては、mkfs.ext4のマンページを参照してください。
Linuxはこの制限なしに他のファイルシステムをサポートします。 btrfs
では、スペースが動的に割り当てられます。 「iノード構造は比較的小さく、埋め込みファイルデータや拡張属性データは含まれません。」 (ext3/4 拡張属性用のiノード内にスペースを割り当てます )。もちろん、メタデータ/ディレクトリエントリを作成しすぎると、ディスク領域が不足する可能性があります。
考えてみると、tmpfsはiノードが動的に割り当てられるもう1つの例です。 df -i
によって報告されるiノードの最大数が実際にこれらのファイルシステムに対して実際に何を意味するかを知るのは困難です。表示されている値には意味を付けません。
「XFSはiノードも動的に割り当てます。JFSもそうです。reiserfsもそうです。F2FSもそうです。従来のUnixファイルシステムは、mkfs時にiノードを静的に割り当てます。そのため、ext4のような最新のFSは、その遺産を追跡しますが、最近ではルールではなく例外。
「ところで、XFSではiノードが使用するスペースの最大パーセンテージに制限を設定できるため、既存のファイルに追加できないポイントに到達する前にiノードが不足する可能性があります。(FSのデフォルトは25%です。 1TB未満、50TBまでのファイルシステムの場合は5%、それよりも大きい場合は1%。)とにかく、メタデータ(ノードとエクステントマップ)のこのスペース使用量は、通常のdf -h
"に反映されます– Peter Cordes この回答へのコメント
空のファイルを作成するには、以下を使用する必要があります。
多くの場合、使用可能なiノードの数は、ファイルシステムの作成時に決定され、変更できません(BtrfsやXFSなどの一部のファイルシステムは、iノードを動的に割り当てます)。それがdf -i
。 iノードが不足すると、使用可能なディスク領域がある場合でも、新しいファイルまたはディレクトリを作成できません。
ディレクトリエントリも、使用可能なディスク領域から領域を占有します。これは、ディレクトリのサイズを確認することで確認できます。これは常にブロックサイズの倍数であり、ディレクトリに多数のファイルが含まれている場合、サイズは大きくなります。ディスク容量が不足すると、「フル」のディレクトリに新しいファイルまたはディレクトリを作成できない場合があります(ie、新しいファイルを追加すると、新しいブロックの割り当てが必要になります)。利用可能なiノードがある場合でも。
したがって、はい、空のファイルのみを使用してディスク領域が不足する可能性があります。
純粋な論理論:
ファイル名は、ゼロ以外のバイト数で構成されています。絶対最大量のファイル名を許可するように設計された仮想ファイルシステムの理論上の最大圧縮を使用しても、各ファイル名は物理ディスク上の少なくとも1ビットどこかを消費します。おそらくもっと多いですが、「ファイルごとに1ビット」が取るに足らない最小値です。
プラッタに収まる可能性のあるビット量を計算します。これは、プラッタに格納できる(空または空でない)ファイルの理論上の最大数です。
だから、答えはイエスです。空のファイルを追加し続けると、最終的には、使用しているストレージに関係なく、スペースが不足します。明らかに、この方法で計算された最大値よりはるかに早く不足しますが、不足します。
単純にそうではありませんが、Linuxでiノードが不足する可能性があります。これは、スペース不足と同じになります。
シェルでこのようなことを試すことができますn=0; while :; do touch $n; let n=n+1; done
必ず仮想マシンで実行してください。そうしないと、iノードが非常に速くなくなります。
空のファイルを作成してディスクをいっぱいにすることはできません。ディスクには、新しいファイル用に十分なスペースがあります。しかし、はい、ファイルシステムの空きiノードの有限供給を使い果たす可能性があります。この時点では、新しいファイルを作成することはできません(ディスク-使用されているスペースの限り-は実質的に空です)。使用されているのはファイルシステムのiノードのリストであり、ディスクではありません。そのため、ファイルシステムはいっぱいになり、ディスクは実質的に空になります。 iノードテーブルはディスク上のスペースを使用しますが、ファイルを追加してもテーブルは大きくなりません-行に書き込むときに紙が大きくならないのと同じように。
(Baard Kopperudによるコメントの回答)