façon tl; dr
Votre diagramme est essentiellement correct.
/dev/<device> des dossiers
Je pense que la façon la plus simple de commencer à répondre à votre question est de savoir quels /dev/<device>sont les fichiers. Disons que vous avez un disque dur. Ce disque dur a une table de partition basée sur MBR, et il a deux partitions, une formatée ext4 avec quelques fichiers dessus, et l'autre configurée pour LVM. Notez que cette réponse parle de création de fichiers de périphérique à la volée, ce qui implique que vous utilisez un noyau Linux. Les choses sont un peu différentes sur les autres Unices.
Lorsque vous branchez ce disque dur (ou lorsque le système le détecte au démarrage), un fichier de périphérique est créé dans le /devrépertoire - généralement appelé soit /dev/sd*ou /dev/hd*(selon le contrôleur utilisé pour connecter le lecteur) - le * est un lettre. Les octets du fichier de périphérique sont essentiellement mappés linéairement aux octets du disque physique: si vous utilisez un outil pour écrire au début du fichier de périphérique, ces données seront également écrites au début physique du disque physique.
Désormais, le système comprend également les tables de partition comme les MBR et les GPT. Une fois le fichier de périphérique initial créé, il sera lu pour déterminer s'il possède une table de partition. Si c'est le cas, des fichiers de périphérique représentant ces partitions seront créés. Ainsi, en supposant que le fichier de périphérique d'origine a été appelé /dev/sda, un fichier de périphérique appelé /dev/sda1sera créé (représentant la première partition au format ext4), ainsi qu'un /dev/sda2périphérique (représentant la deuxième partition LVM). Ceux-ci sont mappés linéairement à leurs partitions respectives de la même manière que le lecteur entier - c'est-à-dire que si vous utilisez un outil pour (par exemple) écrire au début de /dev/sda2, les données écrites seront physiquement écrites au début de la deuxième partition , qui est en fait le milieu du disque entier, car c'est là que la deuxième partition commence.
Blocs et secteurs
C'est le moment idéal pour parler des blocs et des secteurs: ce ne sont que des mesures d'espace sur un disque physique, rien de plus (du moins si je comprends bien). Un secteur est une région physique sur un disque dur; il s'agit généralement de 512 octets - 4 Ko sur les disques durs plus récents. Un bloc est aussi une unité de mesure, c'est presque toujours 8 Ko. Lorsque quelqu'un parle de lecture et d'écriture de blocs, cela signifie simplement qu'au lieu de lire chaque octet de données individuellement, il lit et écrit des données par blocs de 8 Ko.
Systèmes de fichiers et inodes
Ensuite, les systèmes de fichiers et les inodes. Un système de fichiers est un concept assez simple: au début de la région dans laquelle le système de fichiers réside (cette région est généralement une partition), il y a un tas d'informations sur le système de fichiers. Cet en-tête (également appelé superbloc, je crois) est d'abord utilisé pour déterminer quel pilote de système de fichiers doit être utilisé pour lire le système de fichiers, puis il est utilisé par le pilote de système de fichiers choisi pour lire les fichiers. C'est une simplification, bien sûr, mais il stocke essentiellement deux choses (qui peuvent ou non être stockées sous la forme de deux structures de données distinctes sur le disque, selon le type de fs): l'arborescence de répertoires et une liste d'inodes. L'arborescence des répertoires est ce que vous voyez lorsque vous faites un lsou untree. L'arborescence des répertoires indique quels fichiers et répertoires sont les enfants de quels autres répertoires. La relation parent / enfant fichier / répertoire forme l'arborescence de répertoires UNIX telle que nous la connaissons.
Mais l'arborescence de répertoires ne comprend que des noms. Ces noms sont en outre associés à des numéros d'inode. Un numéro d'inode contient des informations comme l'endroit où les morceaux d'un fichier sont physiquement stockés sur le disque. Un inode en soi est simplement "un fichier" sans nom; un inode est associé à un nom via l'arborescence de répertoires. Voir aussi Qu'est-ce qu'un superbloc, un inode, un dentier et un fichier?
Jusqu'à présent, nous avons l'explication suivante: les /dev/sd*fichiers carte sur les disques durs, /dev/sd*#fichiers mapper numéro de la partition #sur /dev/sd*. Un système de fichiers est une structure de données sur disque qui assure le suivi d'une arborescence de répertoires; il est généralement conservé dans une partition ( /dev/sd*#). Un système de fichiers contient des inodes; les inodes sont des nombres qui représentent des fichiers, ainsi que des données associées à ces fichiers (à l'exception de leur nom et de leur position dans l'arborescence des répertoires).
Il convient de noter que les systèmes de fichiers gardent généralement la trace des données dans les blocs. Généralement, l'arborescence des répertoires et la liste des inodes sont stockées dans des blocs, pas dans des octets, et les inodes pointent vers des blocs sur le disque, pas des octets. (Cela peut entraîner des problèmes lorsque les fichiers gaspillent généralement un demi-bloc d'espace, car le système de fichiers a alloué un bloc entier mais n'a pas eu besoin d'utiliser ce bloc entier pour la dernière partie du fichier.)
Le mappeur de périphériques
La dernière pièce du puzzle est un module très important dans le noyau Linux appelé le mappeur de périphériques (chargez-le avec modprobe dm). Le mappeur de périphériques vous permet essentiellement de créer un autre fichier de périphérique dans le /dev/mapperrépertoire. Ce fichier de périphérique est ensuite mappé à une autre source de données, pouvant être transformé au cours du processus. L'exemple le plus simple est la lecture d'une partie d'un fichier.
Supposons que vous ayez une image de disque complet, avec la table de partition. Vous devez lire les données sur l'une des partitions de l'image, mais vous ne pouvez pas accéder uniquement à cette partition, car il s'agit d'une image de disque complet, au lieu d'une image à partition unique. La solution consiste à trouver où se trouve l'image dans votre partition, puis à créer un nouveau fichier de périphérique mappant sur cette partie de l'image disque. Voici un schéma:
.-------------------.
| /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.
Une autre façon de penser est comme un pipeline de transformation (c'est la métaphore la plus précise de ce qui se passe en interne dans le noyau). Imaginez un tapis roulant. Une demande - une lecture, une écriture, etc. - commence à une extrémité de la bande transporteuse, sur un fichier d'appareil créé avec le mappeur d'appareil. La demande parcourt ensuite la transformation du mappeur de périphérique vers le fichier source. Dans l'exemple ci - dessus, ce fichier source est un fichier régulier, diskimage.img. Voici le schéma:
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
Remarquez comment dans le diagramme, la logique de transformation qui a été connectée au mappeur de périphériques a peu d'outils +pour manipuler la demande de lecture lorsqu'elle se déplace sur la bande transporteuse.
Maintenant, je n'ai pas particulièrement envie de copier ce diagramme et de le modifier pour LVM, mais en gros, la partie transformation peut être n'importe quoi - pas seulement déplacer la plage d'octets vers l'avant. Voici comment LVM fonctionne: une étendue physique LVM est la partie de LVM qui se trouve sur le disque et garde une trace de l'emplacement des données. Considérez-le comme le système de fichiers de LVM. Dans la métaphore de la bande transporteuse, une étendue physique est l'un des fichiers source, et la transformation est LVM faisant son travail, mappant une demande sur un volume logique (qui est l'élément le plus à gauche sur la bande transporteuse) aux données physiques sur le disque. En parlant de ça ...
Je suis un peu rouillé sur mes concepts LVM, mais IIRC, un groupe de volumes est essentiellement comme un disque dans LVM. Encore une fois, les niveaux IIRC, RAID, etc. sont gérés par groupe de volumes. Un volume logique est donc comme une partition, et les volumes logiques sont ce qui a réellement des fichiers de périphérique qui les représentent. Vous mettez des systèmes de fichiers et des trucs sur des volumes logiques.
La chose intéressante à propos du mappeur de périphériques est que la logique construite avec lui peut être insérée arbitrairement dans la pile de données - tout ce que vous avez à faire est de changer le nom du périphérique que vous lisez. C'est ainsi que fonctionnent les partitions chiffrées ( pas les schémas de chiffrement qui fonctionnent au niveau du fichier - ceux qui utilisent FUSE), et c'est ainsi que LVM fonctionne. Je ne peux pas penser à d'autres exemples pour le moment, mais croyez-moi, le mappeur de périphériques est assez dur à cuire.
Adressage de bloc logique
Je n'en ai jamais entendu parler, je ne peux donc pas fournir d'informations à ce sujet. J'espère que quelqu'un viendra et modifiera cette réponse.