Inode: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
5 273 byte aggiunti ,  1 nov 2015
rimozione "Guida da adottare"
(Nuova pagina: ==INODE== === Nota === 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 qu...)
 
(rimozione "Guida da adottare")
 
(13 versioni intermedie di 3 utenti non mostrate)
Riga 1: Riga 1:
==INODE==
{{Versioni compatibili}}
 
=== Premessa ===
=== Nota ===
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.


===Che cos'è un inode?===
=== Che cos'è un inode? ===


Un inode è una struttura che viene utilizzata quando un filesystem viene creato per salvare le informazioni dei file, quali i diritti di accesso, la dimensione, l'uid e il gid ecc... (http://en.wikipedia.org/wiki/Inode) quando questi vengono aperti .
Un inode è una struttura che viene utilizzata quando un filesystem viene creato per salvare le informazioni dei file, quali i diritti di accesso, la dimensione, l'uid e il gid ecc... (http://en.wikipedia.org/wiki/Inode) quando questi vengono aperti .
Riga 14: 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 36: 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 63: 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 91: Riga 90:
</pre>
</pre>


's_inodes'
's_inodes' : il numero di inode è fisso ma solitamente nei filesystem è possibile cambiare questo numero nel superblock. Alcuni si saranno accorti che su alcuni filesystem quando gli inode sono esauriti bisogna aumentarne il numero e riservare ulteriore spazio altrimenti non sarà più possibile salvare alcun file anche se c'è dello spazio disponibile.
il numero di inode è fisso ma solitamente nei filesystem è possibile cambiare questo numero nel superblock. Alcuni si saranno accorti che su alcuni filesystem quando gli inode sono esauriti bisogna aumentarne il numero e riservare ulteriore spazio altrimenti non sarà più possibile salvare alcun file anche se c'è dello spazio disponibile.


Per curiosità il campo s_magic definisce il tipo di filesystem .
Per curiosità il campo s_magic definisce il tipo di filesystem .
Un altra cosa a cui dobbiamo dare attenzione sono i campi unsigned short s_imap_blocks : questo campo definisce il blocco che contiene la bitmap degli inode e cioè dove si trovano i blocchi che contengono delle strutture di inode .
Un altra cosa a cui dobbiamo dare attenzione sono i campi unsigned short s_imap_blocks : questo campo definisce il blocco che contiene la bitmap degli inode e cioè dove si trovano i blocchi che contengono delle strutture di inode .


=== Creiamo il nostro filesystem minix e spiamolo ===
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).
 
<pre>
Bisognera' usare root per montare in lodevice il file cha andreamo a creare, per cui attenzione a non fare danni.
 
$ dd if=/dev/zero of=minixfs count=10 bs=1024
  10+0 records in               
  10+0 records out               
  10240 bytes (10 kB) copied, 0.000333843 seconds, 30.7 MB/s
 
# losetup /dev/loop0 minixfs
# mkfs.minix /dev/loop0
  32 inodes
  10 blocks
  Firstdatazone=5 (5)
  Zonesize=1024
  Maxsize=268966912
 
questi valori ci serviranno dopo quando andremo a vedere cosa c'è dentro il nostro filesystem .
# mount -t minix /dev/loop0 /mnt/data/
$
</pre>
 
Andremo ora a fare delle semplici prove per vedere come cambiano i dati nel nostro filesystem appena creato e come cambiano gli inode su disco (fare riferimento al paragrafo precedente per una descrizione degli inode contenuti in memoria dal kernel TODO) usando hexdump come tool.
 
Come detto il primo blocco è vuoto, per cui partiamo dal secondo blocco che contiene il superblock:
 
<pre>
$ hexdump minixfs -C  -n 1024 -s 0x400
  00000400  20 00 0a 00 01 00 01 00  05 00 00 00 00 1c 08 10  | ...............|
  00000410  8f 13 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  00000420  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  *
  00000800
</pre>
 
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>


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 .
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

Menu di navigazione