way tl; dr
Il diagramma è essenzialmente corretto.
/dev/<device> File
Penso che il modo più semplice per iniziare a rispondere alla tua domanda sia con quali /dev/<device>file sono. Supponi di avere un disco rigido. Questo disco rigido ha una tabella delle partizioni basata su MBR e ha due partizioni, una ext4 formattata con alcuni file su di essa e l'altra configurata per LVM. Nota che questa risposta parla della creazione di file di dispositivo al volo, il che implica che stai usando un kernel Linux. Le cose sono leggermente diverse su altri Unices.
Quando si collega questo disco rigido (o quando il sistema lo rileva all'avvio) verrà creato un file del dispositivo nella /devdirectory - generalmente chiamato /dev/sd*o /dev/hd*(a seconda del controller utilizzato per connettere l'unità) - * è un lettera. I byte sul file del dispositivo sono essenzialmente mappati linearmente ai byte sul disco fisico: se si utilizza uno strumento per scrivere all'inizio del file del dispositivo, anche quei dati verranno scritti all'inizio fisico del disco fisico.
Ora, il sistema comprende anche le tabelle delle partizioni come MBR e GPT. Una volta creato il file iniziale del dispositivo, verrà letto per determinare se ha una tabella delle partizioni. In tal caso, verranno creati i file del dispositivo che rappresentano queste partizioni. Supponendo quindi che sia stato chiamato il file del dispositivo originale /dev/sda, /dev/sda1verrà creato un file del dispositivo chiamato (che rappresenta la prima partizione formattata ext4), nonché un /dev/sda2dispositivo (che rappresenta la seconda partizione LVM). Questi sono mappati linearmente sulle 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 fisicamente scritti all'inizio della seconda partizione , che in realtà è il mezzo dell'intero disco, perché è lì che inizia la seconda partizione.
Blocchi e settori
Questo è un momento conveniente per parlare di blocchi e settori: sono solo misurazioni dello spazio su un disco fisico, niente di più (almeno se ho capito bene). Un settore è una regione fisica su un disco rigido; è in genere 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, ciò significa semplicemente che invece di leggere ogni byte di dati singolarmente, legge e scrive i dati in blocchi di 8 KB.
File system e inode
Successivamente, filesystem e inode. Un filesystem è un concetto abbastanza semplice: all'inizio della regione in cui risiede il filesystem (questa regione è generalmente una partizione), ci sono un sacco di informazioni sul filesystem. Questa intestazione (anche definita superblocco, credo) viene prima utilizzata per determinare quale driver del filesystem dovrebbe essere usato per leggere il filesystem, e poi viene usato dal driver del filesystem scelto per leggere i file. Questa è una semplificazione, ovviamente, ma fondamentalmente memorizza due cose (che possono essere o meno archiviate come due distinte strutture di dati sul disco, a seconda del tipo di fs): l'albero delle directory e un elenco di inode. L'albero delle directory è quello che vedi quando fai un lso untree. L'albero delle directory indica quali file e directory sono i figli di cui altre directory. La relazione genitore-figlio file / directory forma l'albero di directory UNIX come lo conosciamo.
Ma l'albero delle directory include solo nomi. Quei nomi sono inoltre associati ai numeri di inode. Un numero di inode contiene informazioni come dove i pezzi di un file sono fisicamente memorizzati su disco. Un inode da solo è semplicemente "un file" senza nome; un inode è associato a un nome tramite l'albero delle directory. Vedi anche Cos'è un Superblock, Inode, Dentry e un file?
Finora, abbiamo la seguente spiegazione: i /dev/sd*file vengono mappati su dischi rigidi, i /dev/sd*#file vengono mappati #sul numero di partizione /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 (ad eccezione del nome e della posizione nella struttura della 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 memorizzati in blocchi, non in byte, e gli inode puntano a blocchi sul disco, non a byte. (Ciò può causare problemi in cui i file in genere sprecano mezzo blocco di spazio, poiché il file system ha allocato un intero blocco ma non è stato necessario utilizzare l'intero blocco per l'ultima parte del file.)
Il mappatore del dispositivo
L'ultimo pezzo del puzzle è un modulo molto importante nel kernel di Linux chiamato device mapper (caricalo con modprobe dm). Fondamentalmente il Device Mapper ti consente di creare un altro file di dispositivo nella /dev/mapperdirectory. Il file del dispositivo viene quindi mappato su un'altra fonte di dati, eventualmente trasformandosi nel processo. L'esempio più semplice è la lettura di una parte di un file.
Supponi di avere un'immagine a disco intero, completa della tabella delle partizioni. Hai bisogno di leggere i dati fuori una delle partizioni nell'immagine, ma non si può arrivare a solo quella partizione, in quanto si tratta di un'immagine completa del disco, l'immagine di una singola partizione al posto di. La soluzione è trovare dove si trova la tua partizione nell'immagine, quindi creare un nuovo mapping dei file del dispositivo a quella porzione 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 pensarci è come una pipeline di trasformazione (questa è la metafora più accurata di ciò che sta accadendo internamente nel 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 mappatore del dispositivo. La richiesta passa quindi attraverso la trasformazione del mapper del dispositivo al file di origine. Nell'esempio di cui sopra, questo file di origine è un file regolare, 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
Notare come nel diagramma, la logica di trasformazione che è stata collegata con il mappatore del dispositivo ha piccoli strumenti +per 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 in sostanza, la parte di trasformazione può essere qualsiasi cosa, non solo spostare la gamma di byte in avanti. Ecco come funziona LVM: un'estensione fisica LVM è la parte di LVM che si trova sul disco e tiene traccia della posizione dei 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. Ancora una volta, i livelli IIRC, RAID, ecc. Sono gestiti per gruppo di volumi. Un volume logico, quindi, è proprio come una partizione e i volumi logici sono ciò che in realtà hanno i file del dispositivo che li rappresentano. Metti filesystem e cose sui volumi logici.
La cosa interessante di 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 gli schemi di crittografia che funzionano a livello di file - quelli usano FUSE), ed è così che funziona LVM. Non riesco a pensare ad altri esempi al momento, ma fidati di me, il dispositivo mapper è piuttosto tosto.
Indirizzamento del blocco logico
Non ne ho mai sentito parlare, quindi non posso offrire alcuna informazione al riguardo. Spero che qualcuno venga e modifichi questa risposta.