ファイルのサイズを合計すると、1つの図が表示されます。 du
を実行すると、別の図が表示されます。パーティション上のすべてのファイルに対してdu
を実行すると、df
クレームが使用されているものと一致しません。ファイルの合計サイズにさまざまな数値があるのはなぜですか?コンピューターは追加できませんか?
追加と言えば、df
の「Used」列と「Available」列を追加すると、合計数がわかりません。そして、その合計数は私のパーティションのサイズよりも小さいです。パーティションサイズを合計すると、ディスクサイズがわかりません!何ができますか?
数字の加算は簡単です。問題は、追加する多くの異なる数があることです。
基本的な考え方は、nバイトを含むファイルは、nバイトのディスク領域と、いくつかの制御情報用のビットを使用するということです。ファイルのメタデータ(権限、タイムスタンプなど)、およびシステムがファイルの保存場所を見つけるために必要な情報のためのオーバーヘッド。しかし、多くの合併症があります。
各ファイルは、ライブラリ内の一連の本と考えてください。小さいファイルは1つのボリュームを構成しますが、大きいファイルは百科事典のように多くのボリュームで構成されます。ファイルを見つけることができるようにするために、すべてのボリュームを参照するカードカタログがあります。各ボリュームはカバーのために少しオーバーヘッドがあります。ファイルが非常に小さい場合、このオーバーヘッドは比較的大きくなります。また、カードカタログ自体もある程度のスペースを取ります。
もう少し技術的に言えば、典型的な単純なファイルシステムでは、スペースはblocksに分割されます。一般的なブロックサイズは4KiBです。各ファイルは整数のブロックを占めます。ファイルサイズがブロックサイズの倍数でない限り、最後のブロックは部分的にしか使用されません。したがって、1バイトのファイルと4096バイトのファイルはどちらも1ブロックを使用しますが、4097バイトのファイルは2ブロックを使用します。これは、du
コマンドで確認できます。ファイルシステムに4KiBのブロックサイズがある場合、du
は1バイトのファイルに対して4KiBを報告します。
ファイルが大きい場合、ファイルを構成するブロックのリストを格納するためだけに追加のブロックが必要です(これらは間接ブロックです。より高度なファイルシステムでは、 エクステントの形式)。 ls -l
またはGNU du --apparent-size
; du
は、サイズではなくディスク使用量を報告しますが、これらを考慮に入れて、ファイルサイズに表示されません。
一部のファイルシステムは、最後のブロックに残っている空き領域を再利用して、同じブロックにいくつかのファイルの末尾を パックしようとします 。一部のファイルシステム(Linux 3.8以降の ext4など) は、iノードに完全に収まる小さなファイル(わずか数バイト)に0ブロックを使用します。
一般に、上記のように、du
によって報告される合計サイズは、ファイルによって使用されるブロックまたはエクステントのサイズの合計です。
ファイルが圧縮されている場合、du
によって報告されるサイズは小さくなる場合があります。 Unixシステムは伝統的に大まかな形式の圧縮をサポートします。ファイルブロックにnullバイトのみが含まれる場合、ゼロのブロックを格納する代わりに、ファイルシステムはそのブロックを完全に省略できます。このようにブロックが省略されたファイルはスパースファイルと呼ばれます。一連の大きなnullバイトがファイルに含まれている場合、スパースファイルは自動的に作成されません。アプリケーションは、ファイルがスパースになるように調整する必要があります。
btrfs や zfs などの一部のファイルシステムは、汎用圧縮をサポートしています。
Zfsやbtrfsなどの非常に最近のファイルシステムの2つの主要な機能により、ファイルサイズとディスク使用量の関係が大幅に遠くなります。スナップショットと重複排除です。
スナップショットは、特定の日付におけるファイルシステムの凍結状態です。この機能をサポートするファイルシステムには、異なる日に作成された複数のスナップショットを含めることができます。もちろん、これらのスナップショットには余裕があります。極端な例として、アクティブなバージョンのファイルシステムからすべてのファイルを削除しても、スナップショットが残っている場合、ファイルシステムは空になりません。
スナップショット以降、または2つのスナップショットが取得されてから変更されていないファイルまたはブロックは、スナップショットとアクティブなバージョンまたは他のスナップショットに同じように存在します。これは copy-on-write によって実装されます。一部のEdgeのケースでは、使用可能なスペースが不足しているために、ファイルシステム全体のファイルを削除すると失敗する可能性があります。そのファイルを削除すると、ディレクトリにブロックのコピーを作成する必要があり、その1つのブロックでさえも空きがなくなるためです。
Deduplicationは、同一のブロックの保存を回避することからなるストレージ最適化手法です。典型的なデータでは、重複を探すことは常に努力する価値があるとは限りません。 zfs と btrfs は両方とも、オプション機能として重複排除をサポートしています。
du
の合計がファイルサイズの合計と異なるのはなぜですか?上記で見たように、各ファイルのdu
によって報告されるサイズは、通常、ファイルが使用するブロックまたはエクステントのサイズの合計です。デフォルトでは、ls -l
はサイズをバイト単位でリストしますが、du
はサイズをKiBで、またはいくつかの従来のシステムでは512バイト単位(セクター)でリストします(du -k
はキロバイトの使用を強制します)。最近のほとんどのuniceはls -lh
およびdu -h
をサポートしており、K、M、Gなどを使用して「人間が読める」数値を使用できます。必要に応じて(KiB、MiB、GiBの場合)十分です。
ディレクトリでdu
を実行すると、ディレクトリツリー内のすべてのファイルのディスク使用量が合計されますディレクトリを含む自体。ディレクトリにはデータ(ファイルの名前、およびファイルのメタデータがある場所へのポインター)が含まれているため、少しのストレージスペースが必要です。小さなディレクトリは1ブロックを占め、大きなディレクトリはより多くのブロックを必要とします。ディレクトリが使用するストレージの量は、ディレクトリに含まれるファイルだけでなく、それらが挿入された順序や一部のファイルが削除された順序にも依存します(一部のファイルシステムでは、これにより穴が残る可能性があります。ディスクスペースとパフォーマンスの妥協点) )、ただし、違いはわずかです(あちこちに余分なブロックがあります)。 ls -ld /some/directory
を実行すると、ディレクトリのサイズがリストされます。 (ls -l
からの出力の上部にある「合計NNN」行は無関係な数値であることに注意してください。これは、KiBまたはセクターで表される、リストされたアイテムのブロック内のサイズの合計です。)
du
にはドットファイルが含まれることに注意してください。ls
は、-A
または-a
オプションを使用しない限り表示されません。
場合によっては、du
が予期した合計より少ないと報告することがあります。これは、ディレクトリツリー内にハードリンクがある場合に発生します。du
は各ファイルを1回だけカウントします。
LinuxのZFS
などの一部のファイルシステムでは、du
は、ファイルの拡張属性が占めるディスク領域全体を報告しません。
ディレクトリの下にマウントポイントがある場合、-x
オプションを指定しない限り、du
はこれらのマウントポイント上のすべてのファイルもカウントすることに注意してください。たとえば、ルートファイルシステム内のファイルの合計サイズが必要な場合は、du -x /
ではなくdu /
を実行します。
ファイルシステムが空でないディレクトリにマウントされている場合 、そのディレクトリ内のファイルはマウントされたファイルシステムによって非表示になります。彼らはまだ彼らのスペースを占めていますが、du
は彼らを見つけません。
ファイルがdeletedの場合、これはディレクトリエントリのみを削除し、ファイル自体は削除しません。ファイルを実際に削除して、そのディスク領域を再利用するには、2つの条件が必要です。
fuser -m
または lsof
には、ファイルが削除されていても、そのファイルシステムでファイルを開いているプロセスが含まれます。loop
デバイスのバックエンドである場合、ファイルのスペースは回収されない可能性があります。 losetup -a
(root
として)は、現在設定されているloop
デバイスと、どのファイルにあるかを通知します。ループデバイスは、ディスク領域を解放する前に(losetup -d
を使用して)破棄する必要があります。一部のファイルマネージャーまたはGUI環境でファイルを削除すると、そのファイルはゴミ箱の領域に置かれ、削除を取り消すことができます。ファイルの削除を取り消すことができる限り、そのスペースは引き続き消費されます。
df
からのこれらの数字は正確に何ですか?典型的なファイルシステムには以下が含まれます:
du
が報告するのは第1種のみです。 df
に関しては、「used」、「available」、およびtotalの列に含まれるものはファイルシステムによって異なります(もちろん、使用済みブロック(間接ブロックを含む)は常に「used」列にあり、未使用ブロックは常に「利用可能」列)。
Ext2/ext3/ext4のファイルシステムreserve rootユーザーにスペースの5%。これは、ルートファイルシステムで、システムがいっぱいになった場合にシステムを継続させるのに役立ちます(特にロギングの場合、およびシステム管理者が問題を修正する間、少しのデータを保存できるようにするため)。 /home
などのデータパーティションの場合でも、ほぼ完全なファイルシステムは断片化する傾向があるため、その予約領域を維持すると便利です。 Linuxは、ファイルの書き込み時に多くの連続するブロックを事前に割り当てることにより、断片化(特にハードディスクなどの回転機械デバイスでファイルアクセスを遅くします)を回避しようとしますが、連続するブロックが多くない場合は機能しません。 。
Ext4までのbtrfsを含まない従来のファイルシステムでは、ファイルシステムの作成時に、固定数inodesを予約しています。これはファイルシステムの設計を大幅に簡素化しますが、iノードの数を適切に設定する必要があるという欠点があります。iノードが多すぎると、スペースが無駄になります。 inodeが少なすぎると、ファイルシステムは領域が不足する前にiノードが不足する可能性があります。コマンドdf -i
は、使用中のiノードの数と使用可能な数を報告します(この概念が適用されないファイルシステムは0を報告する場合があります)。
Ext2/ext3/ext4ファイルシステムを含むボリュームでtune2fs -l
を実行すると、空きiノードとブロックの総数と数を含むいくつかの統計が報告されます。
問題を混乱させる可能性があるもう1つの機能はsubvolumes( btrfs 、および datasets という名前のzfsでサポートされています)。複数のサブボリュームは同じスペースを共有しますが、個別のディレクトリツリールートがあります。
ファイルシステムがネットワーク(NFS、Sambaなど)を介してマウントされ、サーバーがそのファイルシステムの一部をエクスポートする場合(たとえば、 サーバーには/home
ファイルシステムがあり、/home/bob
をエクスポートします)、クライアントでdf
クライアントにエクスポートおよびマウントされた部分だけでなく、ファイルシステム全体のデータを反映します。
上記で見たように、df
によって報告される合計サイズは、常にファイルシステムのすべての制御データを考慮しているわけではありません。必要に応じて、ファイルシステム固有のツールを使用して、ファイルシステムの正確なサイズを取得します。たとえば、ext2/ext3/ext4では、tune2fs -l
を実行し、ブロックサイズにブロック数を掛けます。
ファイルシステムを作成すると、通常、それを含むパーティションまたはボリュームの使用可能なスペースがいっぱいになります。ファイルシステムを移動したり、ボリュームのサイズを変更したりすると、ファイルシステムが小さくなることがあります。
Linuxでは、lsblk
は使用可能なストレージボリュームの概要を示します。追加情報について、またはlsblk
がない場合は、専用のボリューム管理またはパーティション化ツールを使用して、どのパーティションがあるかを確認してください。 Linuxには、 [〜#〜] lvm [〜#〜]のlvs
、vgs
、pvs
、 、 fdisk
(従来のPCスタイル(「MBR」)パーティション用)最近のシステムのGPT)、 gdisk
for [〜#〜] gpt [〜#〜] パーティション、 disklabel
BSDディスクラベル用、 Parted などLinuxでは、cat /proc/partitions
が簡単な要約を提供します。通常のインストールには、オペレーティングシステムが使用する少なくとも2つのパーティションまたはボリュームがあります。ファイルシステム(場合によってはそれ以上)と swap ボリュームです。
一部のコンピューターには、 [〜#〜] bios [〜#〜] またはその他の診断ソフトウェアを含むパーティションがあります。 [〜#〜] uefi [〜#〜] がインストールされているコンピュータには、専用のブートローダーパーティションがあります。
最後に、ほとんどのコンピュータープログラムは、1024 = 2の累乗に基づく単位を使用することに注意してください。10 (プログラマーはバイナリーと2の累乗が大好きなため)。したがって、1 kB = 1024 B、1 MB = 1048576 B、1 GB = 1073741824、1 TB = 1099511627776 B、…公式には、これらの単位は kibibyte KiB、 mebibyte MiBとして知られています。など。ただし、ほとんどのソフトウェアはkまたはkB、MまたはMBなどを報告するだけです。一方、ハードディスクメーカーは体系的にメトリック(1000ベースの単位)を使用します。つまり、1 TBドライブは931 GiBまたは0.904 TiBです。
ファイルサイズとディスク容量の計算の複雑さの簡単な要約:
ファイルがディスク上で占有するスペースは、各ブロックのサイズ+ファイルが占有するiノードの数に対して、ファイルが占有するブロック数の乗数です。 1バイト長のファイルには、少なくとも1つのブロック、1つのiノード、および1つのディレクトリエントリが必要です。
ただし、ファイルが別のファイルへのハードリンクである場合、追加のディレクトリエントリは1つしか必要ありません。これは、同じブロックセットへの別の参照になります。
ls
が表示するものです。これはファイルシステムの表面をなぞっただけで、過度に単純化されています。また、ファイルシステムが異なると、動作も異なります。
stat
は、この情報の一部を見つけるのに非常に役立ちます。以下に、statの使用方法とその使用例をいくつか示します。 http://landoflinux.com/linux_stat_command_examples.html
ここでは、du
がdf
と異なる原因となるさまざまなケースを示します。
df
はファイルシステムに割り当てられたブロックをカウントし、du
は各ファイルのサイズ情報を使用します。違いには多くの原因があります。
1)アプリケーションによってまだ開かれているリンク解除(削除)ファイル。ファイル情報が欠落していますが、ブロックはまだ割り当てられています。 lsof +aL1 <filesystem>
は、プロセスを特定するのに役立ちます。ほとんどの場合、スペースを解放するためにプロセスを強制終了する必要があります(プロセスによって異なります。構成の再読み込みで十分な場合もあります)。
2)du
に隠されているがdf
には隠されていないマウントポイントの下のファイル。 debugfs
は、ファイルシステムを読み取るのに役立ちます。
$ Sudo debugfs
debugfs 1.42.12 (29-Aug-2014)
debugfs: open /dev/xxx (the desired file system device)
debugfs: cd /boot
debugfs: ls -l
1966081 40755 (2) 0 0 4096 26-May-2016 16:28 .
2 40555 (2) 0 0 4096 11-May-2016 10:43 ..
1974291 100644 (1) 0 0 0 26-May-2016 16:28 bob <---<<< /boot/bob is hidden by /boot fs
3) スパースファイル 現実よりも大きく見えます。割り当てられていないブロックはdf
ではカウントされませんが、見かけのファイルサイズはdu
でカウントされます。
ハードリンクはdu
をだますことはありません。
df
は通常、ファイルシステムの内容、各ファイルシステムの空き容量、マウントされている場所を確認するために使用されます。ファイルシステムのスペースが不足していて、ファイルシステム間で移動したり、より大きなディスクを購入したりする場合などに非常に役立ちます。
du
は、各ディレクトリが消費している累積ストレージの詳細を示します(Windowsのwindirstat
のようなものです)。ファイルのクリーンアップを行おうとするときに、スペースを独占している場所を見つけるのに最適です。
他の人が説明する小さな数値の違いは別として、du
およびdf
ユーティリティは非常に異なる目的で機能すると思います。