☰

Winziges Verzeichnis im Ext4-Dateisystem, das 2024 Blöcke einnimmt?

tag-icon • tag-icon filesystems directory ext4
Winziges Verzeichnis im Ext4-Dateisystem, das 2024 Blöcke einnimmt?

Ich habe ein ext4-Dateisystem auf meinem Arbeitscomputer und bin auf ein Verzeichnis gestoßen, das >1 MB Speicherplatz beansprucht. Das Verzeichnis enthält 7 Einträge. Das Verzeichnis enthielt nie mehr als 20 Einträge.

Was ist hier los? Das Verzeichnis hat mir bisher keine Probleme bereitet. Muss ich mir Sorgen machen?

Soweit ich weiß, habe ich auf dem Volume keine ACLs oder Extents eingerichtet. Als ich es erstellt habe, habe ich die Standardblockgröße von 4096 verwendet.

=[3 dc@work ~/documents/work/foo ]= $ ls -lat -r
[...]
drwxr-xr-x  2 dchurch users    4096 Dec 23 11:53 _old/
drwxr-xr-x  5 dchurch users    4096 Dec 30 17:43 ./
drwxr-xr-x  3 dchurch users 1032192 Jan  2 08:51 account_import/
drwxr-xr-x 14 dchurch users    4096 Jan  2 08:54 ../
=[3 dc@work ~/documents/work/foo ]= $ ls -la account_import/
total 5500
drwxr-xr-x 3 dchurch users 1032192 Jan  2 08:51 ./
drwxr-xr-x 5 dchurch users    4096 Dec 30 17:43 ../
drwxr-xr-x 2 dchurch users    4096 Jan  2 08:54 _first/
-rw-r--r-- 1 dchurch users  804852 Dec 17 15:37 ca.csv
-rw-r--r-- 1 dchurch users    3495 Dec 17 16:14 slurp.php
-rw-r--r-- 1 dchurch users    3707 Dec 17 16:13 slurp.php~
-rw-r--r-- 1 dchurch users 3769577 Dec 17 15:37 us.csv
=[3 dc@work ~/documents/work/foo ]= $ stat account_import
  File: 'account_import'
  Size: 1032192         Blocks: 2024       IO Block: 4096   directory
Device: 804h/2052d      Inode: 4458105     Links: 3
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ dc)   Gid: (  100/   users)
Access: 2015-01-05 04:40:11.629350078 -0600
Modify: 2015-01-02 08:51:06.024793685 -0600
Change: 2015-01-02 08:51:06.024793685 -0600
 Birth: -

Antwort1

4096B ist nur die Anfangsgröße des Verzeichnisses, gleich einem Sektor. Wenn jedoch die zu speichernde Datenmenge (Metadaten, einschließlich Dateinamen) wächst, wächst auch die Größe des Verzeichnisses, ohne dass es jemals wieder abnimmt, um Probleme mit der Festplattenfragmentierung zu verringern:

 $ mkdir testdir
 $ cd testdir
 $ ls -lhd .
   drwxrwxr-x 2 me me 4.0K Jan  5 18:06 .
 $ for ((i=0; i<1000; i++)); do touch this_is_a_long_file_name_$i; done 
 $ ls -lhd .
   drwxrwxr-x 2 me me 64K Jan  5 18:08 .
 $ rm this*
 $ ls -lhd .
   drwxrwxr-x 2 me me 64K Jan  5 18:09 .

BEARBEITEN: Dies ist das gleiche Experiment für Reiserfs:

 $ mkdir testdir
 $ cd testdir
 $ ls -lhd .
   drwxr-xr-x 2 me me 48 gen  5 18:54 .
 $  for ((i=0; i<1000; i++)); do touch this_is_a_really_long_file_name_$i; done
 $ !ls
   ls -lhd .
   drwxr-xr-x 2 me me 55K gen  5 18:55 .
 $ rm this*
 $ !ls
   ls -lhd .
   drwxr-xr-x 2 me me 48 gen  5 18:55 .

Und das hier ist für xfs:

 $ mkdir testdir
 $ cd testdir
 $ ls -lhd .
   drwxr-xr-x 2 me me 6 gen  5 19:00 .
 $ for ((i=0; i<1000; i++)); do touch this_is_a_really_long_file_name_$i; done
 $ ls -lhd .
   drwxr-xr-x 2 me me 48K gen  5 19:01 .
 $ rm this*
 $ !ls
   ls -lhd .
   drwxr-xr-x 2 me me 6 gen  5 19:01 .

Es ist offensichtlich, dass wederReiserfsnoch xfs* kümmert sich so sehr um die Festplattenfragmentierung, da die Verzeichnisgröße nach dem Löschen der zahlreichen Dateien auf ihren ursprünglichen Wert zurückgesetzt wird.

verwandte Informationen