Re: [RiminiLUG-General] Partizioni, File System ecc.

[Massimo Gengarelli <massi@xxxxxxxxxxxx>]

Il 23/04/2011 23:32, Andrea Urbinati ha scritto:
> Blocchi, inode, insomma *cosa* e *come* viene scritto un HD?

Blocchi e inode sono termini tecnici appartenenti solo ai filesystem
Ext* e ReiserFS. Puoi pensare agli i-node come a dei puntatori a diversi
blocchi, ogni i-node contiene informazioni sul tipo di blocco a cui punta.
Per fare un esempio pratico (reminescenze dell'esame di sistemi
operativi), supponi di avere un disco con 5 i-node e 10 blocchi di dati
da 1024byte ciascuno e di voler ricreare la struttura

/usr/bin/programma, dove programma è un file contenente dati (in questo
caso un eseguibile) di 2048 byte.

Avrai: il primo i-node (0) che sarà di tipo "d" (directory), dimensione
irrilevante, che punta al primo blocco dati, quest'ultimo conterrà
soltanto il nome della cartella e relativo i-node, nel nostro caso ". 0"
e un elenco di tutte le sue sotto cartelle e i loro rispettivi i-node di
appartenenza, esempio "usr 1"

Passiamo all'i-node 1, che è ancora di tipo "d", dimensione irrilevante
e punta al blocco dati 1, il blocco dati 1 sarà simile a quello visto in
precedenza e contiene il proprio nome col proprio i-node ". 1", il nome
del padre col suo i-node ".. 0" e il nome dei figli col loro i-node "bin 2".

Per bin sarà la stessa identica cosa, ma conterrà anche "programma" col
suo i-node ("programma 3", ad esempio).

L'i-node di "programma" è invece più interessante, perché sarà di tipo
"f" (file), dimensione 2048 e non punterà ad un solo blocco dati (ogni
blocco è di 1024 byte), ma a due blocchi dati, con due puntatori diretti.

I blocchi dati a cui punta l'i-node 3 conterranno l'esatto contenuto
dell'eseguibile.

Quindi la struttura finale sarà, per gli i-node:

numero   tipo   dimensione   blocco dati 1    blocco dati 2
0         d          /          0                  /
1         d          /          1                  /
2         d          /          2                  /
3         f        2048         3                  4


mentre per i blocchi dati:
numero                    contenuto
0                          ".. 0"
                           ". 0"
                           "usr 1"

1                          ".. 0"
                           ". 1"
                           "bin 2"

2                          ".. 1"
                           ". 2"
                           "programma 3"

3                          "ABABABBABBAAAA" (1024)

4                          "BABBABBABBABAB" (1024)




Questo rende i filesystem basati su struttura i-node blocchi, dei
filesystem più che solidi e veloci (per spostare un file ad esempio
basta cambiare l'i-node di riferimento), ma molto più soggetti ad
errori, molte operazioni di spostamento/copia/rinomina possono lasciare
buchi negli i-node o nei blocchi dati, che poi è più difficile
utilizzare perché si preferisce la contiguità dei dati. Per ovviare a
questo problema è stato introdotto il meccanismo del "diario" (o
"giornale", come lo chiamava Davoli a lezione), dove praticamente il
filesystem memorizza le azioni che l'utente vuole eseguire in un diario
- appunto - e le esegue solo alla fine in modo da ottimizzarle il più
possibile. Per questo motivo è *fortemente sconsigliato* staccare un
disco con fs basato su journal senza prima smontarlo in modo pulito,
molte operazioni potrebbero andare perdute o - ancora peggio - essere
eseguite a metà, e questo porterebbe indubbiamente ad una corruzione del
filesystem.


FAT32 invece è un po' più semplice, sostanzialmente nella prima parte
del disco viene allocata una tabella che contiene dei "puntatori" al
blocco dati successivo. Non ha un journal, quindi le operazioni vengono
fatte "al volo" (e.g. è più difficile corrompere un FAT32 staccandolo
brutalmente dal PC), ma ha bisogno di deframmentazioni perenni e spesso
si "perdono" byte su byte se i blocchi sono stati scelti male dal
filesystem.


NTFS è molto simile ad Ext4, ma per qualche motivo a me ignoto è molto
più soggetto ad errori (probabilmente non è colpa della Microsoft o di
Windows, semplicemente l'utente medio Windows è fondamentalmente
ignorante e stacca hard-disk/pennette mentre stanno copiando.. forse noi
utenti Linux siamo più "responsabili")



ReiserFS è molto simile ad Ext4, ma è ottimizzato per molti file di
piccole dimensioni (di default ha un varello di i-node e blocchi molto
piccoli). (No dai, la battuta sul "Murders your wife" non la faccio a
Pasqua).


XFS è davvero bello: è ottimizzato per i file "con i buchi", tipo gli
hard disk delle macchine virtuali, per intenderci, o per i file che
create con dd o con qemu-img. Provate a copiare un file a ciambella fra
due filesystem XFS e poi a fare la stessa cosa fra due Ext/Reiser: il
primo ci metterà meno di 3 secondi per il semplice motivo che "salterà"
i buchi per poi ricrearli sulla destinazione, Ext invece si ostinerà a
copiare anche i buchi.
Il problema di XFS è che non son mai riuscito a tenerlo pulito, dopo un
po' in un modo o nell'altro si corrompeva. Leggendo in giro ho scoperto
che purtroppo basta un balzo di tensione e il filesystem si rifiuta di
andare avanti, distruggendo praticamente tutto.

Poi ci sono quei fs ottimizzati per pennine o schede sd, tipo yaffs (yet
another fast file system) e yaffs2, ma sinceramente non li ho mai
approfonditi più di tanto. Li prendo per buoni basandomi sulla fiducia :D




Poi basta, non ne conosco altri, ma ce ne sono così tanti che
bisognerebbe farci un libro prima o poi.



Scusate sia per la prolissità che - forse - per il troppo dettaglio
tecnico e per la mancanza di un italiano corretto.. se mi evidenziate i
punti poco chiari magari troviamo il tempo di approfondirli, qui o alle
riunioni (quando riuscirò a liberarmi e venire :-)


-- 
Massimo Gengarelli <massi@xxxxxxxxxxxx>
"The Center promises to always provide a safe testing environment.
In dangerous testing environments, the Center promises to always provide
useful advice.
For instance, the floor here will kill you. Try to avoid it."
     -- GLaDOS