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 qué /dev/<device>archivos están. Digamos que tienes un disco duro. Este disco duro tiene una tabla de particiones basada en MBR, y tiene dos particiones, una ext4 formateada 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 /devdirectorio, generalmente llamado /dev/sd*o /dev/hd*(dependiendo de qué controlador se use para conectar la unidad), el * es un letra. Los bytes en el archivo del dispositivo se asignan esencialmente linealmente a bytes en el disco físico: si usa una herramienta para escribir al comienzo del archivo del dispositivo, esos datos también se escribirán en el comienzo físico del disco físico.
Ahora, el sistema también comprende tablas de particiones como MBR y GPT. Una vez que se haya creado el archivo del 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. Asumiendo que se llamó al archivo original del dispositivo /dev/sda, /dev/sda1se creará un archivo llamado dispositivo (que representa la primera partición formateada ext4), así como un /dev/sda2dispositivo (que representa la segunda partición LVM). Estos se asignan linealmente a sus respectivas particiones de la misma manera que toda la unidad, 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 lo 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 inodes
A continuación, sistemas de archivos e inodes. 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 mucha información sobre el sistema de archivos. Este encabezado (también conocido como el superbloque, creo) se usa primero para determinar qué controlador del sistema de archivos debe usarse para leer el sistema de archivos, y luego lo usa el controlador del sistema de archivos elegido para leer los archivos. Esto 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, dependiendo del tipo fs): el árbol de directorios y una lista de inodes. El árbol de directorios es lo que ves cuando haces una lso unatree. El árbol de directorios indica qué archivos y directorios son los hijos de qué otros directorios. La relación archivo / directorio padre-hijo forma el árbol de directorios UNIX tal como lo conocemos.
Pero el árbol de directorios solo incluye nombres. Esos nombres están asociados adicionalmente con números de inodo. Un número de inodo contiene información como dónde se almacenan físicamente las piezas 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, Inode, Dentry y un Archivo?
Hasta el momento, tenemos la siguiente explicación: /dev/sd*los archivos se asignan a los discos duros, /dev/sd*#archivos de mapas de 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 mantiene en una partición ( /dev/sd*#). Un sistema de archivos contiene inodes; Los inodes son números que representan archivos, junto con los 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 inodes se almacenan en bloques, no en bytes, y los inodes apuntan a bloques en el disco, no en bytes. (Esto puede causar problemas en los que 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 núcleo de Linux llamado mapeador de dispositivos (cárguelo con modprobe dm). El mapeador de dispositivos básicamente le permite crear otro archivo de dispositivo en el /dev/mapperdirectorio. Ese archivo de dispositivo se asigna a otra fuente de datos, posiblemente se transforma en el proceso. El ejemplo más simple es leer una parte de un archivo.
Digamos que tiene una imagen de disco completo, completa con la tabla de particiones. Debe leer los datos de una de las particiones de la imagen, pero no puede acceder solo a 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 está su partición y luego crear un nuevo mapeo de archivos del 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 pensarlo es como una tubería de transformación (esta es la metáfora más precisa de lo que está sucediendo 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. La solicitud luego viaja a través de la transformación del mapeador de dispositivos al archivo fuente. En el ejemplo anterior, el 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 +para manipular la solicitud de lectura a medida que avanza por la cinta transportadora.
Ahora, no tengo muchas ganas de copiar ese diagrama y modificarlo para LVM, pero básicamente, la parte de transformación puede ser cualquier cosa, no solo desplazar 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 lo suyo, asignando 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 que...
Estoy un poco oxidado en mis conceptos de LVM, pero IIRC, un grupo de volúmenes es esencialmente como un disco en LVM. Nuevamente, los niveles de IIRC, RAID, etc. se administran por grupo de volúmenes. Un volumen lógico, entonces, es como una partición, y los volúmenes lógicos son los que realmente tienen archivos de dispositivo que los representan. Pones sistemas de archivos y cosas en volúmenes lógicos.
Lo bueno del mapeador de dispositivos es que la lógica construida 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í es como funcionan las particiones encriptadas ( no los 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 bloque lógico
Nunca he oído hablar de esto, así que no puedo ofrecer ninguna información al respecto. Esperemos que alguien venga y edite esta respuesta.