すべてのディレクトリのサイズが4096バイト(4 K)なのはなぜですか?


33

主題が言うように; 4Kを超えるサイズのファイルが含まれている場合でも、すべてのディレクトリのサイズが4Kに等しい理由を知りたい。

以下をご覧ください。

$ ls -lh
total 2.0M
drwxr-xr-x 4 ankit ankit 4.0K Sep 11 07:28 Desktop

$ ls -lrh Desktop/
-rw-rw-r-- 1 ankit ankit 9.1M Aug 4 11:15 sophosthreatsaurusaz.pdf
-rw------- 1 ankit ankit 107K Dec 27 2010 KP 3 0.pdf
drwxrwsr-x 9 ankit ankit 4.0K Sep 10 19:26 eclipse

PS:du -shコマンドラインユーティリティを知っています。

編集:ディレクトリをファイルのコンテナとして想定しています。


これは、ディレクトリのメタデータである
タキオン

回答:


34
  • 技術的になりすぎることなく、ディレクトリエントリを、ディレクトリが「含む」ファイルのリストへの単なる「リンク」と考えください。
  • 次に、他のすべてと同様に、ディレクトリのコンテンツが占める合計スペースではなく、そのリンクlsのサイズ表示します。
  • ファイルまたはディレクトリエントリ/リンクが占有する必要がある最小サイズは1ブロックです。これは、ほとんどのext3 / 4ファイルシステムで通常4096バイト/ 4Kです。

7
「ファイルまたはディレクトリエントリ/リンクが占有する必要のある最小サイズは1ブロックです」と言いますが、4K未満のファイルサイズを見たことは間違いありません。
ラクシャイガルグ

1
@LakshayGargは、ファイルが4K未満になる可能性がありますが、小さなファイルを保存するためにブロックのほんの数バイトが使用された「内部フラグメンテーション」と呼ばれるものを引き起こします。
phyloflash

@phyloflash一部のファイルシステム(NTFSなど)は、ファイルエントリ自体に小さなファイルを保存します(NTFSの場合、MFTエントリにあります)。このようにして、それらのコンテンツはゼロの割り当てブロックを占有し、内部の断片化が削減されます。
ルスラン

26

これを理解するには、次のファイルシステムに関する基本的な知識が必要です。

  • iノード(ファイル属性、ファイルのメタデータ、ポインター構造を含む)
  • ファイル(ファイル名とそのiノード、iノードがブロックデバイス上の生データブロックを指す2つの列を持つテーブルと見なすことができます)
  • ディレクトリ(特別なファイル、他のファイル名のコンテナ。各ファイル名のファイル名とiノード番号の配列が含まれます。また、親と子の関係についても説明します。)
  • シンボリックリンクVSハードリンク
  • dentry(ディレクトリエントリ)
  • ...

一般的なext4ファイルシステム(ほとんどの人が使用するもの)では、デフォルトinodeサイズは256バイト、ブロックサイズは4096バイトです。

ディレクトリは、ファイル名とiノード番号の配列を含む特別なファイルです。ディレクトリが作成されると、ファイルシステムは「ファイル名」(実際にはディレクトリ名)を持つディレクトリに1つのiノードを割り当てました。iノードは、4096バイトの単一データブロック(最小オーバーヘッド)を指します。そのため、を使用すると4096 / 4.0Kが表示されますls

tune2fs&を使用して詳細を取得できますdumpe2fs

root@ubuntu:~# tune2fs -l /dev/ubuntu/root 
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          2fca4cbb-22f1-4328-ab13-cacedb360930
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              967680
Block count:              3931136
Reserved block count:     0
Free blocks:              2537341
Free inodes:              517736
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      416
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8064
Inode blocks per group:   504
RAID stride:              35637
Flex block group size:    16
Filesystem created:       Thu Mar 15 14:31:04 2012
Last mount time:          Sat Oct 20 20:28:04 2012
Last write time:          Sat Oct 20 20:23:32 2012
Mount count:              1
Maximum mount count:      -1
Last checked:             Sat Oct 20 20:22:57 2012
Check interval:           0 (<none>)
Lifetime writes:          54 GB
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
Journal inode:            8
First orphan inode:       272350
Default directory hash:   half_md4
Directory Hash Seed:      d582ad79-75a0-4964-9a48-33ddba04df5c
Journal backup:           inode blocks

7

ファイルにデータが1つでも含まれている場合(1バイトでも)、ディスク上の1ブロックを占有します(最近では通常4kです)。1つのブロックをファイル間で共有することはできません。これは、そのブロック全体のスペースが他のファイルに使用できないため、「使用済み」と見なされることを意味します。

ソース

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.