web-dev-qa-db-ja.com

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

したがって、e。 g。 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

その欠けているスペースを何が使用していますか？

filesystemsdisk-usageext4
16
misc

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

ファイルシステムには、それぞれ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ブロックで、ジャーナルサイズとして適切な範囲にあります。

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

21
Gilles 'SO- stop being evil'

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

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

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

あなたは確かに次のようなシステムを望んでいます：

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

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

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

13
Juliano
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
1
telcoM