Sono un po' imbarazzato nel porre questa domanda, ma mi piacerebbe vedere un diagramma che mostri come sono correlate le seguenti cose. Sarebbe bello se il diagramma includesse anche le trasformazioni necessarie per mappare anche tra i vari livelli.
A quanto ho capito, credo che siano correlati nel modo seguente, ma non sono sicuro che la mia comprensione sia accurata al 100%.
.-----------------.
| inode |
'-----------------'
|
.-----------------.
| EXT4 |
'-----------------'
|
.---------------------.
| logical volume (LV) | --- part of LVM
'---------------------'
|
.-------------------.
| volume group (VG) | --- part of LVM
'-------------------'
|
.---------------.
| /dev/<device> |
'---------------'
|
.--------------------------------.
| Logical Block Addressing (LBA) |
'--------------------------------'
|
.-----------------.
| blocks/sectors |
'-----------------'
|
HDD
_.-----._
.- -.
|-_ _-|
| ~-----~ |
| |
`._ _.'
"-----"
Riferimenti
- Trovare quali settori del disco rigido occupano un file
- File di identificazione associato al settore del disco illeggibile
- HOWTO sul blocco errato per smartmontools
- C5170 Appunti — Rappresentazione interna dei file – Il file system Unix
- Indirizzamento a blocchi logici
- Layout disco Ext4
Risposta accettata:
modo tl;dr
Il tuo diagramma è sostanzialmente corretto.
/dev/<device> file
Penso che il modo più semplice per iniziare a rispondere alla tua domanda sia con cosa /dev/<device> i file sono. Supponiamo di avere un disco rigido. Questo disco rigido ha una tabella delle partizioni basata su MBR e ha due partizioni, una formattata ext4 con alcuni file e l'altra configurata per LVM. Nota che questa risposta parla della creazione di file del dispositivo al volo, il che implica che stai utilizzando un kernel Linux. Le cose sono un po' diverse sugli altri Unice.
Quando colleghi questo disco rigido (o quando il sistema lo rileva all'avvio) verrà creato un file del dispositivo in /dev directory – generalmente chiamata /dev/sd* o /dev/hd* (a seconda del controller utilizzato per collegare l'unità) – * è una lettera. I byte sul file del dispositivo sono essenzialmente mappati linearmente ai byte sul disco fisico:se usi uno strumento per scrivere all'inizio del file del dispositivo, quei dati verranno scritti anche all'inizio fisico del disco fisico.
Ora, il sistema comprende anche le tabelle delle partizioni come MBR e GPT. Una volta creato il file del dispositivo iniziale, verrà letto per determinare se ha una tabella delle partizioni. In tal caso, verranno creati i file del dispositivo che rappresentano queste partizioni. Quindi supponendo che il file del dispositivo originale fosse chiamato /dev/sda , un file del dispositivo chiamato /dev/sda1 verrà creato (che rappresenta la prima partizione formattata ext4), nonché un /dev/sda2 dispositivo (che rappresenta la seconda partizione LVM). Questi sono mappati linearmente alle rispettive partizioni allo stesso modo dell'intera unità, ovvero se si utilizza uno strumento per (ad esempio) scrivere all'inizio di /dev/sda2 , i dati scritti verranno scritti fisicamente all'inizio della seconda partizione, che in realtà è il centro dell'intero disco, perché è lì che inizia la seconda partizione.
Blocchi e settori
Questo è un momento comodo per parlare di blocchi e settori:queste sono solo misure di spazio su un disco fisico, niente di più (almeno se ho capito bene). Un settore è una regione fisica su un disco rigido; in genere sono 512 byte - 4 KB su dischi rigidi più recenti. Un blocco è anche un'unità di misura, è quasi sempre 8 KB. Quando qualcuno parla di lettura e scrittura di blocchi, significa semplicemente che invece di leggere ogni byte di dati individualmente, legge e scrive dati in blocchi di 8 KB.
Filesystem e inode
Successivamente, filesystem e inode. Un filesystem è un concetto abbastanza semplice:all'inizio della regione in cui risiede il filesystem (questa regione è solitamente una partizione), ci sono un sacco di informazioni sul filesystem. Questa intestazione (indicata anche come superblocco, credo) viene prima utilizzata per determinare quale driver del filesystem dovrebbe essere utilizzato per leggere il filesystem, quindi viene utilizzata dal driver del filesystem scelto per leggere i file. Questa è una semplificazione, ovviamente, ma fondamentalmente memorizza due cose (che possono o meno essere archiviate come due distinte strutture di dati su disco, a seconda del tipo di fs):l'albero delle directory e un elenco di inode. L'albero delle directory è ciò che vedi quando esegui un ls o un tree . L'albero delle directory indica quali file e directory sono figli di quali altre directory. La relazione genitore-figlio file/directory forma l'albero delle directory UNIX come lo conosciamo.
Ma l'albero delle directory include solo i nomi. Questi nomi sono inoltre associati ai numeri di inode. Un numero di inode contiene informazioni come dove i pezzi di un file sono archiviati fisicamente sul disco. Un inode di per sé è semplicemente "un file" senza nome; un inode è associato a un nome tramite l'albero delle directory. Vedi anche Che cos'è un Superblock, Inode, Dentry e un file?
Finora, abbiamo la seguente spiegazione:/dev/sd* i file vengono mappati sui dischi rigidi, /dev/sd*# i file vengono mappati sul numero di partizione # su /dev/sd* . Un filesystem è una struttura di dati su disco che tiene traccia di un albero di directory; è generalmente tenuto in una partizione (/dev/sd*# ). Un filesystem contiene inode; gli inode sono numeri che rappresentano i file, insieme ai dati associati a tali file (tranne il nome e la posizione nell'albero delle directory).
Vale la pena notare che i filesystem generalmente tengono traccia dei dati in blocchi. Di solito, l'albero delle directory e l'elenco degli inode sono archiviati in blocchi, non in byte, e gli inode puntano a blocchi su disco, non a byte. (Ciò può causare problemi in cui i file in genere sprecano mezzo blocco di spazio, perché il filesystem ha allocato un intero blocco ma non aveva bisogno di utilizzare quell'intero blocco per l'ultima parte del file.)
Il mappatore del dispositivo
L'ultimo pezzo del puzzle è un modulo molto importante nel kernel Linux chiamato device mapper (caricalo con modprobe dm ). Il device mapper ti consente sostanzialmente di creare un altro file di dispositivo nel /dev/mapper directory. Il file del dispositivo viene quindi mappato su un'altra fonte di dati, eventualmente trasformata nel processo. L'esempio più semplice è leggere una parte di un file.
Supponiamo di avere un'immagine del disco intero, completa della tabella delle partizioni. Devi leggere i dati da una delle partizioni nell'immagine, ma non puoi solo quella partizione, poiché è un'immagine a disco intero, anziché un'immagine a partizione singola. La soluzione è trovare dove si trova la partizione nell'immagine, quindi creare una nuova mappatura del file del dispositivo su quella parte dell'immagine del disco. Ecco un diagramma:
.-------------------.
| /dev/mapper/foo | <- This is the device file created with the device mapper
.___________________.
/
/
/ <- This is a small section of the image being mapped to
/ the new device file
/
/
.------------------.
| diskimage.img | <- This is the full-disk image. It's a regular file.
.__________________. Notice how the mapping goes to _part_ of the file.
Un altro modo di pensarlo è come una pipeline di trasformazione (questa è la metafora più accurata di ciò che sta accadendo all'interno del kernel). Immagina un nastro trasportatore. Una richiesta – una lettura, una scrittura, ecc. – inizia a un'estremità del nastro trasportatore, su un file del dispositivo creato con il mapper del dispositivo. La richiesta viaggia quindi attraverso la trasformazione del device mapper nel file di origine. Nell'esempio sopra, questo file sorgente è un file normale, diskimage.img . Ecco il diagramma:
Read operation goes onto
device mapper conveyor belt
read() The device mapper transforms the read The modified read request finally
request by moving the requested region reaches the source file, and the data
Beginning of conveyor belt to read forward by some number of bytes. is retrieved from the filesystem.
.-------------------. .--------------------------. .------------------------.
| /dev/mapper/foo | | Transformation logic | | /path/to/diskimage.img |
.___________________. .___+_____+_____+_____+____. .________________________.
-->
---------------------------------------------------------------------------------------------------------------
o o o o o o o o o o o
Nota come nel diagramma, la logica di trasformazione che è stata collegata al device mapper ha piccoli strumenti (+ s) manipolare la richiesta di lettura mentre si sposta sul nastro trasportatore.
Ora, non ho particolarmente voglia di copiare quel diagramma e modificarlo per LVM, ma fondamentalmente, la parte di trasformazione può essere qualsiasi cosa, non solo spostare l'intervallo di byte in avanti. Ecco come funziona LVM:un'estensione fisica LVM è la parte di LVM che si trova sul disco e tiene traccia di dove si trovano i dati. Pensalo come il filesystem di LVM. Nella metafora del nastro trasportatore, un'estensione fisica è uno dei file di origine e la trasformazione è LVM che fa la sua cosa, mappando una richiesta su un volume logico (che è l'elemento più a sinistra sul nastro trasportatore) ai dati fisici su disco. A proposito...
Sono un po' arrugginito sui miei concetti LVM, ma IIRC, un gruppo di volumi è essenzialmente come un disco in LVM. Anche in questo caso, IIRC, livelli RAID, ecc. sono gestiti per gruppo di volumi. Un volume logico, quindi, è proprio come una partizione e i volumi logici sono ciò che effettivamente hanno file di dispositivo che li rappresentano. Metti filesystem e cose su Logical Volumes.
La cosa interessante del device mapper è che la logica costruita con esso può essere inserita arbitrariamente nello stack di dati:tutto ciò che devi fare è cambiare il nome del dispositivo che stai leggendo. Ecco come funzionano le partizioni crittografate (non schemi di crittografia che funzionano a livello di file (quelli usano FUSE), ed è così che funziona LVM. Al momento non mi vengono in mente altri esempi, ma fidati, il device mapper è piuttosto tosto.
Indirizzamento blocco logico
Non ne ho mai sentito parlare, quindi non posso fornire alcuna informazione in merito. Speriamo che qualcuno passi e modifichi questa risposta.