ドライブ（ext4およびntfs）に実際にどれだけの空き容量がありますか？
私はバックアップを2つの1.5 GBの外付けハードドライブに保存します。両方とも、最近まで、NTFSでフォーマットされていました。 2つは私のファイルとフォルダーの同一のコピーを保持します。最近、ext4に変更することを決めたので、ハードドライブの1つを再フォーマットし、そこにすべてをコピー（rsync）しました。驚いたことに、新しいext4ドライブに約100 GB少ない空き領域があったので、原因を調査しました。
両方のドライブの空き容量を確認しましたが、使用したすべてのアプリケーション/ツールでまったく異なる量が表示されました。
Ext4ドライブの場合：
- 196 GBの空き容量をくれたdf
- Nautilusは210 GBの空き容量をくれました。
- ディスクは私に285 GBの空き容量を与えました、
- Filelightは私に265,4 GBの空き容量を与え、
- GPartedは265,42 GBの空き容量をくれました。
したがって、空き容量は196 GBから285 GBの範囲で、ほぼ100 GBの違いがあります。
Ntfsドライブ（他のドライブと同じコピーを保持）の場合：
- 私に284 GBの空き容量を与えたdf、
- ノーチラスは私に304,9 GBの空き容量を与えました、
- ディスクは305 GBの空き容量を私に与えました、
- Filelightは私に284 GBの空き容量を与え、
- GPartedは284 GBの空き容量をくれました。
このハードドライブの場合、空き容量はより一貫して測定され、20 GBの範囲しかありませんでした。
だから私の質問：本当はどれですか？どれを本当に信じるべきですか？なぜ彼らはそのような異なるスペースサイズを報告するのですか？特にそのようなLinux（ext4）のネイティブ形式に？そして、なぜ2つのシステムの空きスペースにこのような大きな違いがあるのでしょうか。 ext4ドライブの空き容量が増えると思いました。
洞察をありがとう！
ファイルサイズとその結果の空き領域は、アプリケーション間で一貫して計算されません。
これは、ファイルシステムの性質によるものです。データはドライブのblocksに保存されます。一般的なブロックサイズは4096です。つまり、ブロックごとに最大4096バイトのデータを含めることができます。
1バイトのデータのみを含むファイルがある場合、実際にはハードドライブの4096バイトの領域を占有します。
同様に、4097バイトのデータを含むファイルがある場合、2つのブロック、または8192バイトのストレージが予約されます。
各ファイルのデータのサイズをカウントするアプリケーションがある場合、使用されているすべてのブロックの合計をカウントするアプリケーションよりも小さい値になります。
多くのアプリケーションは、ファイルサイズを計算するときに、いくつかの「トリック」を使用してファイルサイズを推定またはキャッシュするため、システムが実際にハードドライブの内容全体を読み取る必要はありません。これは、アプリケーション間の違いを引き起こす可能性もあります。
別の例として、 ls -lがls -s とは異なるサイズを出力する理由をご覧ください。
空き/使用済みファイルサイズが異なるアプリケーションによって異なる方法で報告されるいくつかの追加の理由：
- サイズを「ギガバイト」で報告する人もいれば、 "ギビバイト" で報告する人もいます。
- 特にExt4は、ユーザーが使用できないファイルシステム上のスペースを予約します-フォーマット時にユーザーが指定しない場合、デフォルトで5％です。アプリケーションによっては、ドライブの合計サイズに含まれている場合と含まれていない場合があります。しかし、それがext4ドライブが予想よりも小さく見えることがよくある理由です。