Me da un poco de vergüenza hacer esta pregunta, pero me gustaría ver un diagrama que muestre cómo se relacionan las siguientes cosas. Sería bueno si el diagrama también incluyera las transformaciones necesarias para mapear entre las distintas capas.
Tal como lo entiendo, creo que están relacionados de la siguiente manera, pero no estoy seguro de que mi comprensión sea 100 % precisa.
.-----------------.
| inode |
'-----------------'
|
.-----------------.
| EXT4 |
'-----------------'
|
.---------------------.
| logical volume (LV) | --- part of LVM
'---------------------'
|
.-------------------.
| volume group (VG) | --- part of LVM
'-------------------'
|
.---------------.
| /dev/<device> |
'---------------'
|
.--------------------------------.
| Logical Block Addressing (LBA) |
'--------------------------------'
|
.-----------------.
| blocks/sectors |
'-----------------'
|
HDD
_.-----._
.- -.
|-_ _-|
| ~-----~ |
| |
`._ _.'
"-----"
Referencias
- Encontrar qué sectores del disco duro ocupan un archivo
- Identificación de archivo asociado con sector de disco ilegible
- CÓMO de bloques defectuosos para smartmontools
- C5170 Notas de clase:representación interna de archivos:el sistema de archivos Unix
- Direccionamiento de bloques lógicos
- Diseño de disco Ext4
Respuesta aceptada:
camino tl;dr
Su diagrama es esencialmente correcto.
/dev/<device> archivos
Creo que la forma más básica de comenzar a responder su pregunta es con what /dev/<device> los archivos son. Digamos que tiene un disco duro. Este disco duro tiene una tabla de particiones basada en MBR y tiene dos particiones, una con formato ext4 con algunos archivos y la otra configurada para LVM. Tenga en cuenta que esta respuesta habla sobre la creación de archivos de dispositivos sobre la marcha, lo que implica que está utilizando un kernel de Linux. Las cosas son un poco diferentes en otros Unices.
Cuando conecte este disco duro (o cuando el sistema lo detecte en el momento del arranque), se creará un archivo de dispositivo en el /dev directorio:generalmente llamado /dev/sd* o /dev/hd* (según el controlador que se use para conectar la unidad):el * es una letra. Los bytes en el archivo del dispositivo se asignan esencialmente de forma lineal a los bytes en el disco físico:si usa una herramienta para escribir al principio del archivo del dispositivo, esos datos también se escribirán en el principio físico del disco físico.
Ahora, el sistema también comprende tablas de partición como MBR y GPT. Una vez que se haya creado el archivo de dispositivo inicial, se leerá para determinar si tiene una tabla de particiones. Si lo hace, se crearán archivos de dispositivo que representan estas particiones. Suponiendo que el archivo del dispositivo original se llamara /dev/sda , un archivo de dispositivo llamado /dev/sda1 se creará (que representa la primera partición con formato ext4), así como un /dev/sda2 dispositivo (que representa la segunda partición LVM). Estos se asignan linealmente a sus respectivas particiones de la misma manera que la unidad completa, es decir, si usa una herramienta para (por ejemplo) escribir al comienzo de /dev/sda2 , los datos escritos se escribirán físicamente al comienzo de la segunda partición, que en realidad es el medio de todo el disco, porque ahí es donde comienza la segunda partición.
Bloques y sectores
Este es un momento conveniente para hablar sobre bloques y sectores:estas son solo medidas de espacio en un disco físico, nada más (al menos si entiendo correctamente). Un sector es una región física en un disco duro; por lo general, es de 512 bytes:4 KB en discos duros más nuevos. Un bloque también es una unidad de medida, casi siempre es de 8 KB. Cuando alguien habla de leer y escribir bloques, eso solo significa que en lugar de leer cada byte de datos individualmente, leen y escriben datos en fragmentos de 8 KB.
Sistemas de archivos e inodos
A continuación, sistemas de archivos e inodos. Un sistema de archivos es un concepto bastante simple:al comienzo de la región en la que reside el sistema de archivos (esta región suele ser una partición), hay un montón de información sobre el sistema de archivos. Este encabezado (también conocido como superbloque, creo) se usa primero para determinar qué controlador de sistema de archivos debe usarse para leer el sistema de archivos, y luego lo usa el controlador de sistema de archivos elegido para leer archivos. Esta es una simplificación, por supuesto, pero básicamente almacena dos cosas (que pueden almacenarse o no como dos estructuras de datos distintas en el disco, según el tipo de fs):el árbol de directorios y una lista de inodos. El árbol de directorios es lo que ves cuando haces un ls o un tree . El árbol de directorios establece qué archivos y directorios son los hijos de qué otros directorios. La relación padre-hijo de archivo/directorio forma el árbol de directorios de UNIX tal como lo conocemos.
Pero el árbol de directorios solo incluye nombres. Esos nombres también están asociados con números de inodo. Un número de inodo contiene información como dónde se almacenan físicamente las partes de un archivo en el disco. Un inodo en sí mismo es simplemente "un archivo" sin nombre; un inodo está asociado con un nombre a través del árbol de directorios. Consulte también ¿Qué es un superbloque, un inodo, un dentry y un archivo?
Hasta ahora, tenemos la siguiente explicación:/dev/sd* los archivos se asignan a los discos duros, /dev/sd*# los archivos se asignan al número de partición # en /dev/sd* . Un sistema de archivos es una estructura de datos en el disco que realiza un seguimiento de un árbol de directorios; generalmente se guarda en una partición (/dev/sd*# ). Un sistema de archivos contiene inodos; Los inodos son números que representan archivos, junto con datos asociados con esos archivos (excepto por su nombre y posición en el árbol de directorios).
Vale la pena señalar que los sistemas de archivos generalmente realizan un seguimiento de los datos en bloques. Por lo general, el árbol de directorios y la lista de inodos se almacenan en bloques, no en bytes, y los inodos apuntan a bloques en el disco, no a bytes. (Esto puede causar problemas cuando los archivos generalmente desperdician medio bloque de espacio, porque el sistema de archivos asignó un bloque completo pero no necesitaba usar ese bloque completo para la última parte del archivo).
El mapeador de dispositivos
La pieza final del rompecabezas es un módulo muy importante en el kernel de Linux llamado mapeador de dispositivos (cárgalo con modprobe dm ). El mapeador de dispositivos básicamente le permite crear otro archivo de dispositivo en el /dev/mapper directorio. Ese archivo de dispositivo luego se asigna a otra fuente de datos, posiblemente transformándose en el proceso. El ejemplo más simple es leer una parte de un archivo.
Digamos que tiene una imagen de disco completa, completa con la tabla de particiones. Debe leer los datos de una de las particiones de la imagen, pero no puede llegar a solo esa partición, ya que es una imagen de disco completo, en lugar de una imagen de una sola partición. La solución es encontrar en qué parte de la imagen se encuentra su partición y luego crear una nueva asignación de archivos de dispositivo a esa parte de la imagen del disco. Aquí hay un diagrama:
.-------------------.
| /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.
Otra forma de verlo es como una canalización de transformación (esta es la metáfora más precisa de lo que sucede internamente en el núcleo). Imagina una cinta transportadora. Una solicitud (una lectura, una escritura, etc.) comienza en un extremo de la cinta transportadora, en un archivo de dispositivo creado con el mapeador de dispositivos. Luego, la solicitud viaja a través de la transformación del mapeador de dispositivos hasta el archivo de origen. En el ejemplo anterior, este archivo fuente es un archivo normal, diskimage.img . Aquí está el diagrama:
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
Observe cómo en el diagrama, la lógica de transformación que se ha conectado con el mapeador de dispositivos tiene pequeñas herramientas (+ s) para manipular la solicitud de lectura a medida que avanza en la cinta transportadora.
Ahora, no tengo ganas de copiar ese diagrama y modificarlo para LVM, pero básicamente, la parte de transformación puede ser cualquier cosa, no solo cambiar el rango de bytes hacia adelante. Así es como funciona LVM:una extensión física de LVM es la parte de LVM que se encuentra en el disco y realiza un seguimiento de dónde están los datos. Piense en ello como el sistema de archivos de LVM. En la metáfora de la cinta transportadora, una Extensión física es uno de los archivos de origen, y la transformación es LVM haciendo su trabajo, mapeando una solicitud en un Volumen lógico (que es el elemento más a la izquierda en la cinta transportadora) a los datos físicos en el disco. Hablando de eso...
Estoy un poco oxidado con mis conceptos de LVM, pero IIRC, un grupo de volumen es esencialmente como un disco en LVM. Nuevamente, IIRC, los niveles de RAID, etc. se administran por grupo de volumen. Entonces, un volumen lógico es como una partición, y los volúmenes lógicos son los que en realidad tienen archivos de dispositivo que los representan. Pones sistemas de archivos y otras cosas en volúmenes lógicos.
Lo bueno del mapeador de dispositivos es que la lógica creada con él se puede insertar arbitrariamente en la pila de datos:todo lo que tiene que hacer es cambiar el nombre del dispositivo que está leyendo. Así funcionan las particiones cifradas (no esquemas de encriptación que funcionan a nivel de archivo (esos usan FUSE), y así es como funciona LVM. No puedo pensar en ningún otro ejemplo en este momento, pero confía en mí, el mapeador de dispositivos es bastante rudo.
Direccionamiento de bloques lógicos
Nunca he oído hablar de esto, así que no puedo ofrecer ninguna información al respecto. Con suerte, alguien vendrá y editará esta respuesta.