ext4：ファイルシステムのスペースを考慮する方法は？

ntfsをext4に置き換えることを意図して、最近1.5 TBドライブをフォーマットしました。

次に、保存したファイルが新しいパーティションに収まらないことに気付きました。

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate

1Kブロックの違いは、使用可能なスペースが22 GiB少ないことを意味します。

私はすでに実行しています

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0

当然、そこには存在しないブロックには影響しないため、効果はありません。

それでも、fdiskはext4パーティションがディスク全体をカバーすると報告しています。

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT

したがって、たとえば、resize2fsは「何もしない」と報告します。

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks

不足しているスペースは何を使用していますか？

どれどれ。デバイスのサイズは1,465,138,583½kB = 1,500,301,909,504 Bです。ファイルシステムは、それぞれ4096 Bの366,284,288ブロックで構成され、それぞれ1,500,300,443,648 Bです。残りの1,465,856 B（1.4 MB）が（スーパーブロックの追加コピー？ブートローダー用の先頭に数キロバイトのスペースがあることを知っています。

ファイルシステムには、それぞれ256バイトの91,578,368個のiノードが含まれ、23,444,062,208 B（約22 GB、ヒント、ヒント）を占有します。次に、ファイルのコンテンツには1,442,146,364 kB = 1,476,757,876,736 Bがあります。これは23,444,062,208 B + 1,476,757,876,736 B = 1,500,201,938,944 Bです。残りのサイズは98,504,704 B = 24,029ブロックで、ジャーナルサイズとして適切な範囲にあります。

ご覧のとおり、すべてが説明されています。（わかりました、ほとんどすべてですが、私達はギガバイトではなくメガバイトを話している。）

まず第一に、あなたが見ている利用可能なスペースの違いは、スペースが「浪費されている」ということを意味するものではありません。ファイルシステムが機能するために基本的に重要であるため、無駄になりません。非常に大きな「しかし」ファイルシステム間のすべての設計と構造の違い、および各実装の詳細（たとえば、各ドライバーがVFSレイヤーに空きスペースを報告する方法）を指定せずに、この方法でExt4とNTFSを比較しないでください。

パーティションを、所有するデータを置くことができる巨大なスペースと想像してください。パーティションと同じサイズのデータ​​が1つしかない場合は、パーティションの先頭から書き込みを開始し、それを使ってクールにすることができます。しかし、あなたはしません。代わりに、数千の小さなファイルがあり、これらすべてのファイルがさまざまな方法でグループ化され、各ファイルが他の多くの小さなデータ（名前、日付/時刻、アクセス許可）などに関連付けられている場合があります。これらのすべてのデータに迅速かつ効率的にアクセスできるように、パーティションを作成します。また、新しいデータを書き込み、古いデータを効率的に破棄する方法に注意する必要があります。データ構造が必要です。

そして、多くのデータ構造があります。それらのいくつかは非常に愚かです、他のものはより遅い書き込みを犠牲にしてより速くデータを取得することを可能にします、他は読み取りを犠牲にしてより速く書き込みを許可します、いくつかはまだ読み取りと書き込みの両方で非常に良いかもしれませんが、長い一時停止を必要としますデータの再配置中のアイドルオーバーヘッドなど

あなたは確かに次のようなシステムが必要です：

1. 情報の書き込みが非常に高速です。
2. それから情報を取得するのは非常に高速です。
3. 格納されている情報の整理と管理が得意です。
4. ファイルシステムが保存されているスペース（パーティション）を有効に活用します。
5. ハードウェアの問題に対して回復力があるため、部分的なシステム障害が発生してもほとんどまたはすべての情報を取得できます。
6. ソフトウェアの問題に対する回復力があるため、アプリケーションのバグやインストールされた悪意のあるアプリケーションがデータを永久に破壊することはありません。
7. 人為的エラーに対して回復力があるため、誤ってシステムに削除すべきでないもの（ごみ箱/ごみ箱）を削除するように命令した場合にそれが許されます。

高性能ファイルシステムでは、ある程度のスペースを犠牲にして非常に高速な読み取りと書き込みが可能です。ハッシュテーブルやBツリーなど、ファイルシステムで使用される最速のデータ構造の一部は非常に複雑であり、非常に高速なアクセスを可能にするために実際に使用されているよりも多くのスペースを確保します。

Ext4には他の重要なプロパティがあります。ファイルシステムに単一障害点はありません。パーティション全体に広がる重要なデータのコピーは多数ありますが、適切な場所で障害が発生した場合、他のファイルシステム（NTFSの場合は言えません）がすべてのデータを読み取れない可能性があります。また、Ext4はファイルシステムの作成段階でデータ用に多くのスペースを確保しますが、NTFSはデータとともに成長します。

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! 
The util fdisk doesn't support GPT. Use GNU Parted.

このメッセージは、ディスクがGPTスタイルのパーティション分割を使用していることを示し、このfdiskツールはレガシーMBRスタイルのみを理解します。

GPTパーティションディスクが古い非GPT対応システムに接続されている場合、偶発的な再フォーマットを防止するために、GPTパーティションスキームには「保護MBR」が含まれます：基本的に「このディスクは完全に使用中のパーティションタイプMBRパーティショニングのみを理解しているオペレーティングシステムまたはツールについては何も知らない」。

のパーティションテーブルを正確に表示するには/dev/sdb、次を使用します。

parted /dev/sdb print