Inode: differenze tra le versioni

3 617 byte aggiunti ,  1 nov 2015
rimozione "Guida da adottare"
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 anaalizzare il contenuto nel disco non saranno esatti.
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 utilizata dal kernel (non ho ripetuto le note già dette) :
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.


==== Creamo il nostro filesystem minix e spiamolo ====
==== 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]]
3 581

contributi