Crescita monotonica della dimensione della directory di Linux / numero di blocchi

8

Su Linux, (forse in funzione della dimensione del blocco del filesystem), quando creo una directory e statrestituisce una dimensione di 4096. Posso creare file in questa directory, fino a un certo punto, senza aumentare la dimensione percepita del directory (come riportato da stat).

Ad un certo punto, mentre la directory si riempie di molti file, le dimensioni della directory si gonfiano (non sto parlando del contenuto della directory, sto parlando dei blocchi consumati per rappresentare la directory stessa). Se i file vengono eliminati, la dimensione della directory rimane la stessa.

Ecco un breve esempio:

[root@uxlabtest:/]$ mkdir test
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:04.000000000 -0400
Change: 2011-07-26 14:06:04.000000000 -0400

Quindi tocca un mucchio di file:

[root@uxlabtest:/]$ for i in `seq 1 10000`; do touch /test/$i; done
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:56.000000000 -0400
Change: 2011-07-26 14:06:56.000000000 -0400

Quindi eliminare i file:

[root@uxlabtest:/]$ rm -rf /test/*
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:07:11.000000000 -0400
Modify: 2011-07-26 14:07:12.000000000 -0400
Change: 2011-07-26 14:07:12.000000000 -0400

Le mie domande sono:

Perché la dimensione / il conteggio dei blocchi di una directory aumenta monotonicamente?
È una funzione del file system sottostante o del VFS di Linux?
Le dimensioni della directory possono mai essere ridotte senza eliminare e ricreare la directory?
Punti bonus: indicami il codice sorgente del kernel in cui è implementato questo comportamento.

linux inode vfs

— loopforever
fonte

Non sono davvero sicuro del motivo per cui questo è sotto votato. Queste sono domande legittime e chiaramente espresse con comandi dati per replicare lo scenario. Le risposte a queste domande soddisferebbero le conoscenze della comunità e sarebbe utile documentarle da qualche parte.

— loopforever

9

Ecco le risposte vere per ext2 / ext3 / ext4. Se sono veri per altri file system dipende dalla loro implementazione.

user48838 ha risposto correttamente. Più file consumano più metadati. Sono allocati in blocchi di 4k o in qualsiasi altra dimensione definita al momento della creazione del file system
Sì, è una caratteristica / problema del vero file system
In un file system ext3 questo non è possibile. Solo ricreando la directory (vuota)
Il codice sorgente è qui intorno e nei file correlati

Ma tu hai fortuna. Quando si ricrea la stessa quantità di file già eliminati, le dimensioni della directory rimarranno le stesse. Solo quando aggiungi più file aumenterà.

— mailq
fonte

1

Una cosa: "e2fsck -fD" dovrebbe compattare ogni directory in un filesystem ext2 / 3. Questo può fare ciò che l'OP desidera, anche se sospetto che sia lento e il filesystem deve essere offline. Questo probabilmente richiede più tempo del collegamento di ogni file in una nuova directory e dell'eliminazione di quelli vecchi.

— Akramer

4

Gli incrementi di blocco visualizzati sono dovuti al modo in cui il file system gestisce la memorizzazione dei file e le relative informazioni di gestione dei file. Nella situazione descritta, ciò sembrerebbe con incrementi di 4K, quindi ogni "nuova" / "unica" voce nel file system riserverà 4K, indipendentemente dal fatto che la dimensione effettiva dei dati riempia l'intero 4K. Se i dati correlati occupano l'intero 4K, un altro blocco 4K viene riservato e riempito secondo necessità per memorizzare l'intero flusso / sequenza di dati correlati.

A seconda delle eliminazioni "rigide" rispetto a "deboli" gestite dal file system, la cancellazione potrebbe non (di solito non per la funzionalità "ripristina") liberare immediatamente i blocchi prenotati. Alcuni file system possono differenziare diversi tipi di "eliminazioni" e fornire funzionalità di gestione dei blocchi di archiviazione corrispondenti.

Il modo in cui la gestione dell'archiviazione viene affrontata e implementata differisce dai file system, quindi nei sistemi operativi che supportano file system multipli / modulari, il sistema operativo in genere fornisce solo "hook" per l'integrazione del file system.

— user48838
fonte

1

Aggiunta di alcuni commenti sconclusionati alla buona risposta di user48838:

Tutto è un file, comprese le directory. Per memorizzare tutte le informazioni sul file, è necessario spazio.

Sarebbe anche valido mostrare, per esempio, "64B usato" per una piccola directory e mostrare effettivamente la quantità di spazio utilizzato, ma utilizzeremmo comunque multipli di 4K su disco, quindi è stata una decisione di progettazione mostrare solo il quantità di spazio utilizzato.

Dal punto di vista del design di FS, perché dovresti preoccuparti di affrontare il problema del calcolo di ciò che è stato utilizzato? Non necessario. E poi dovresti spostare le voci per evitare di lasciare buchi ... ick.

Quando le eliminazioni avvengono e la dimensione della directory diminuisce in modo da poter liberare un blocco, tutto ciò che la gestione dovrebbe avere luogo prima di poterlo effettivamente fare. Perché preoccuparsi di salvare qualche KB? Le probabilità sono che dovrai espanderlo in seguito comunque.

Lasciato come esercizio per il lettore: pensa al perché la tua directory / lost + found viene creata vuota ma occupa 16K (almeno su ext3).

— MikeyB
fonte