ARGOMENTO:

Ciao a tutti,

in merito alle discrepanze osservate oggi negli esempi relativi all'utilizzo del filesystem, ed in particolare al conteggio di inode e blocchi di dati, la spiegazione è piuttosto semplice.

Inode

Partendo dallo stato inziale, in cui la partizione '/dev/sdb1' non è montata, eseguiamone il mount nel mountpoint /opt:

Il filesystem è inizialmente vuoto, e possiamo ottenere informazioni circa blocchi e inode dal corrispondente superblocco, nonché tramite il comando df (l'opzione -i mostra info sugli inode):
Come si vede, gli inode liberi coincidono in entrambi i casi (128005).

Ora creiamo un semplice file di testo in /opt:

e ripetiamo il check sul numero di inode in uso:

I due comandi mostrano valori differenti; in particolare, il superblocco non risulta allineato con lo stato reale del filesystem, del quale abbiamo usato un inode per il nuovo file allocato. Il comando df mostra correttamente che c'è un inode disponibile in meno (128004 invece dei 128005 presenti prima di creare il file hello.txt).

Il motivo di questa discrepanza sta nel fatto che la versione aggiornata del superblocco è mantenuta in memoria, e viene effettivamente riportata sul filesystem solo al momento del umount dello stesso. Le opzioni sync/async in questo caso non hanno effetto sul superblocco; al più influiscono sulle modalità di scrittura dei blocchi di dati. Un eventuale spegnimento improvviso del sistema in questo momento, cioè prima che il filesystem sia smontato correttamente, provocherebbe una inconsistenza, tuttavia il recovery sarebbe estremamente rapido grazie al journal del filesystem (ext4).

Blocchi
Per quanto concerne i blocchi, vale lo stesso discorso. Il superblock del filesystem non è aggiornato in tempo reale sul disco perché la versione aggiornata è quella mantenuta dal kernel in memoria. Tuttavia si era detto che la dimensione del singolo file non poteva essere inferiore alla dimensione del blocco del filesystem (nel caso dell'esempio, il filesystem aveva blocchi di dimensione 1024 byte, ovvero 1kByte). L'output del comando ls, invece, mostrava la dimensione reale del contenuto del file, ovvero pochi byte. Il motivo, in questo caso, è relativo alle opzioni passate al comando ls, che di default mostra la dimensione effettiva del file, ovvero del suo contenuto (in questo caso 7 byte, cioè la lunghezza della stringa Hello! più un byte dovuto al terminatore di riga):

Per mostrare la dimensione del file in termini di blocchi del filesystem, è necessario specificare l'opzione -s:

Il numero di blocchi da 1k occupati dal file hello.txt è mostrato nella prima colonna, ed è pari a 1.

Un modo più comodo (ed esplicito) per verificare che effettivamente un file di pochi byte occupa comunque lo spazio di un intero blocco del filesystem è quello di usare il comando du:

Come si osserva, la dimensione del file hello.txt è esattamente di 1K.

Memorizzazione dati inline (opzionale)
Una particolarità introdotta con ext4, ma in genere non attivata di default, è quella che permette di mantenere i dati di un file direttamente all'interno del corrispondente inode, senza necessariamente allocare un intero blocco di dati qualora lo spazio richiesto dai dati stesso sia molto ridotto. Infatti, in genere per un inode vengono allocati 128 o 256 byte, molti dei quali non vengono utilizzati per memorizzare i metadati. Nell'esempio del nostro filesystem ext4, la dimensione degli inode è ovviamente impostata al momento della formattazione ed è pari a 128 byte:
Tuttavia la funzione <strong>inline_data</strong> non è attiva:
Nel nostro esempio, però, non è possibile impostare la feature inline_data su un filesystem esistente (o almeno non si può fare usando tune2fs):

Possiamo però allocare un nuovo filesystem su una nuova partizione, impostanto la feature inline_data al momento della formattazione:

In questo caso la dimensione dell'inode viene impostata a 256 bytes.

Se ora creiamo un nuovo file contenente pochi caratteri, vedremo che il numero di blocchi occupati dal file sarà comunque zero:

In realtà, anche in questo caso, l'output di ls -ls mostrerà sempre un numero di blocchi allocati diverso da zero. Idem usando il comando stat. L'unico modo per osservare il reale utilizzo di blocchi è attraverso il domando debugfs, invocato sul filesystem in questione, e all'interno della cui console si può eseguire il comando stat: