3 581
contributi
Nessun oggetto della modifica |
(rimozione "Guida da adottare") |
||
(10 versioni intermedie di 3 utenti non mostrate) | |||
Riga 1: | Riga 1: | ||
{{Versioni compatibili}} | |||
=== Premessa === | === Premessa === | ||
Spero di fare cosa gradita nel condividere alcuni appunti del filesystem del kernel 0.0.1 che sto studiando. Tuttavia, non posso garantire che quanto scritto qui sia perfettamente esatto, ma solo deduzioni da quanto ho appreso fino ad oggi. La guida è in fase di creazione e di correzione nel tempo . Grazie per la vostra comprensione e per le correzioni che chiunque potrà fare. | Spero di fare cosa gradita nel condividere alcuni appunti del filesystem del kernel 0.0.1 che sto studiando. Tuttavia, non posso garantire che quanto scritto qui sia perfettamente esatto, ma solo deduzioni da quanto ho appreso fino ad oggi. La guida è in fase di creazione e di correzione nel tempo . Grazie per la vostra comprensione e per le correzioni che chiunque potrà fare. | ||
Riga 12: | Riga 13: | ||
==== Linux 0.0.1 e minixfs ==== | ==== Linux 0.0.1 e minixfs ==== | ||
Bisogna premettere che il filesystem di minix che Linus ha utilizzato per il suo primo os (che ancora non era maturo ma funzionante come kernel, bisognerà aspettare qualche versione successiva) è molto diverso dalla versione 3 dei nostri giorni (Lo stesso Linus cambierà in seguito codice per adattarlo alla versione del fs minix 1.6 ), per questo nel paragrafo che segue alcuni campi che troveremo andando ad | Bisogna premettere che il filesystem di minix che Linus ha utilizzato per il suo primo os (che ancora non era maturo ma funzionante come kernel, bisognerà aspettare qualche versione successiva) è molto diverso dalla versione 3 dei nostri giorni (Lo stesso Linus cambierà in seguito codice per adattarlo alla versione del fs minix 1.6 ), per questo nel paragrafo che segue alcuni campi che troveremo andando ad analizzare il contenuto nel disco non saranno esatti. | ||
Il filesystem minix (ma non solo questo, ext2 è nato in un certo senso da minix fs e quindi non sorprendentemente ha gli stessi concetti di base) è diviso in blocchi da 1k (come vedremo in seguito quando lo creeremo). | Il filesystem minix (ma non solo questo, ext2 è nato in un certo senso da minix fs e quindi non sorprendentemente ha gli stessi concetti di base) è diviso in blocchi da 1k (come vedremo in seguito quando lo creeremo). | ||
Riga 34: | Riga 35: | ||
}; | }; | ||
oltre a questa struttura possiamo subito introdurre quella più completa ed | oltre a questa struttura possiamo subito introdurre quella più completa ed utilizzata dal kernel (non ho ripetuto le note già dette) : | ||
struct m_inode { | struct m_inode { | ||
Riga 61: | Riga 62: | ||
come si può vedere ci sono due diverse strutture . La prima è quella che fisicamente viene salvata su disco e identifica le entry che esistono fisicamente nel fs (filesystem), mentre la seconda ha una parte in comune con la prima e inoltre avrà altri campi che si troveranno solamente in memoria organizzati in una tabella di inode. | come si può vedere ci sono due diverse strutture . La prima è quella che fisicamente viene salvata su disco e identifica le entry che esistono fisicamente nel fs (filesystem), mentre la seconda ha una parte in comune con la prima e inoltre avrà altri campi che si troveranno solamente in memoria organizzati in una tabella di inode. | ||
Prima di spiegare meglio alcuni campi che possono essere poco chiari e legati strettamente al funzionamento di minixfs, tutte le operazioni che il nostro filesystem esegue sugli inode si trovano nel file sorgente fs/inode.c . Meglio quindi dargli una lettura almeno parziale . | Prima di spiegare meglio alcuni campi che possono essere poco chiari e legati strettamente al funzionamento di minixfs, tutte le operazioni che il nostro filesystem esegue sugli inode si trovano nel file sorgente <code>fs/inode.c</code> . Meglio quindi dargli una lettura almeno parziale . | ||
==== Il superblock ==== | ==== Il superblock ==== | ||
Riga 96: | Riga 97: | ||
Il codice del superblock si tova in linux/fs/super.c . In questo file si trovano le routine per fare il mount del superblock (e quindi la sua descrizione completa) e del device di root. | Il codice del superblock si tova in linux/fs/super.c . In questo file si trovano le routine per fare il mount del superblock (e quindi la sua descrizione completa) e del device di root. | ||
==== | ==== Creiamo il nostro filesystem minix e spiamolo ==== | ||
Per mettere in pratica i concetti appena esposti creaimo un piccolo filesystem minix (serve mkfs.minix e che si abbia almeno un device di loop). Come detto prima il fs in questione non è esattamente come quello che Linus ha usato, ma la versione 3, per cui alcune cose saranno lievemente diverse (per esempio il magic number). | Per mettere in pratica i concetti appena esposti creaimo un piccolo filesystem minix (serve mkfs.minix e che si abbia almeno un device di loop). Come detto prima il fs in questione non è esattamente come quello che Linus ha usato, ma la versione 3, per cui alcune cose saranno lievemente diverse (per esempio il magic number). | ||
Riga 135: | Riga 136: | ||
Se confrontate i primi campi del superblock e i dati contenuti su disco potrete ritrovare molte cose stampate quando abbiamo creato il minix fs . | Se confrontate i primi campi del superblock e i dati contenuti su disco potrete ritrovare molte cose stampate quando abbiamo creato il minix fs . | ||
Se ora andiamo a vedere il blocco 5 possiamo vedere la tabella delle entry nel fs . Per comprenderene i campi fate riferimento alla struttura presentata nel paragrafo precedente (struct d_inode). | |||
<pre> | |||
$ ls -la /mnt/data/ | |||
total 2 | |||
drwxr-xr-x 2 root root 64 Nov 15 12:31 . | |||
drwxr-xr-x 5 root root 1024 Sep 28 15:16 .. | |||
$ hexdump minixfs -C -n 1024 -s 0x1000 | |||
00001000 ed 41 00 00 40 00 00 00 83 15 1f 49 00 02 05 00 |.A..@......I....| | |||
00001010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
* | |||
00001400 | |||
</pre> | |||
i primi due byte 41 ed (su macchine Intel) identificano i permessi di accesso, Gli altri due byte l'uid, mentre gli altri 4 la dimensione (00 00 00 40) che infatti in decimale 0x40 è 64 . Gli altri byte identificano l'ora (49 1f 15 83), il gid (notare che a differenza dell'uid occupa un solo byte), un contatore del numero dei link che utilizzano questo inode entry ? (in questo caso 02) e da qui una serie di byte che ci dicono quali blocchi occupano i dati di questo inode, in questo caso essendo "." la dir corrente indica il primo blocco disponibile che e' il numero 5 . | |||
<pre> | |||
$ hexdump minixfs -C -n 1024 -s 0x1400 | |||
00001400 01 00 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
00001410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
00001420 01 00 2e 2e 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
00001430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
00001440 00 00 2e 62 61 64 62 6c 6f 63 6b 73 00 00 00 00 |...badblocks....| | |||
00001450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
* | |||
00001800 | |||
</pre> | |||
Questo e' il contenuto dei dati dove l'inode di "." punta . | |||
Vediamo cosa succede quando creiamo un file . | |||
<pre> | |||
$ echo "Hello World" > /mnt/data/hello.asc | |||
$ ls -la /mnt/data/ | |||
total 3 | |||
drwxr-xr-x 2 root root 96 Nov 15 15:33 . | |||
drwxr-xr-x 5 root root 1024 Sep 28 15:16 .. | |||
-rw-r--r-- 1 root root 12 Nov 15 15:33 hello.asc | |||
$ hexdump minixfs -C -n 1024 -s 0x1000 | |||
00001000 ed 41 00 00 60 00 00 00 24 40 1f 49 00 02 05 00 |.A..`...$@.I....| | |||
00001010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
00001020 a4 81 00 00 0c 00 00 00 24 40 1f 49 00 01 06 00 |........$@.I....| | |||
00001030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
* | |||
00001400 | |||
$ hexdump minixfs -C -n 1024 -s 0x1400 | |||
00001400 01 00 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
00001410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
00001420 01 00 2e 2e 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
00001430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
00001440 02 00 68 65 6c 6c 6f 2e 61 73 63 00 00 00 00 00 |..hello.asc.....| | |||
00001450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | |||
* | |||
00001800 | |||
</pre> | |||
Come si vede, la tabella degli inode è stata aggiornata e nel blocco in cui punta l'inode di ".", che contiene la lista dei file presenti, è stato aggiornato con il nome del nostro nuovo file. | |||
Notare come il primo blocco occupato dai dati nell'inode del file hello.asc è il numero 6 . Se andiamo a vedere questo blocco vedremo i dati del file . | |||
Potete provare se interessati a creare dei link hardware tra gli inode e delle directory, che altro non sono che normali file come "." che contengono una lista di file . | |||
=== Gli inode ai giorni nostri === | === Gli inode ai giorni nostri === | ||
Come acennato prima all'inizio di questa guida, gli inode oggi si trovano a livello di astrazione del VFS (fate riferimento alla mappa del kernel), guardando nel codice di un kernel moderno, ovviamente saranno un po' più complicati e dipendono anche dal tipo di fs che il vostro kernel supporterà in fase di configurazione . | Come acennato prima all'inizio di questa guida, gli inode oggi si trovano a livello di astrazione del VFS (fate riferimento alla mappa del kernel), guardando nel codice di un kernel moderno, ovviamente saranno un po' più complicati e dipendono anche dal tipo di fs che il vostro kernel supporterà in fase di configurazione . | ||
{{Autori | |||
|Autore = [[Utente:Dracul|Dracul]] | |||
}} | |||
[[Categoria:Filesystem]] |
contributi