Je suis un peu gêné de poser cette question mais j'aimerais voir un diagramme qui montre comment les choses suivantes sont liées. Ce serait bien si le diagramme incluait également toutes les transformations nécessaires pour mapper également les différentes couches.
Si je comprends bien, je pense qu'ils sont liés de la manière suivante, mais je ne suis pas sûr que ma compréhension soit exacte à 100 %.
.-----------------.
| inode |
'-----------------'
|
.-----------------.
| EXT4 |
'-----------------'
|
.---------------------.
| logical volume (LV) | --- part of LVM
'---------------------'
|
.-------------------.
| volume group (VG) | --- part of LVM
'-------------------'
|
.---------------.
| /dev/<device> |
'---------------'
|
.--------------------------------.
| Logical Block Addressing (LBA) |
'--------------------------------'
|
.-----------------.
| blocks/sectors |
'-----------------'
|
HDD
_.-----._
.- -.
|-_ _-|
| ~-----~ |
| |
`._ _.'
"-----"
Références
- Rechercher les secteurs du disque dur qui occupent un fichier
- Identification du fichier associé à un secteur de disque illisible
- Bad block HOWTO pour smartmontools
- C5170 Notes de cours — Représentation interne des fichiers – Le système de fichiers Unix
- Adressage de bloc logique
- Disposition du disque Ext4
Réponse acceptée :
chemin tl;dr
Votre diagramme est essentiellement correct.
/dev/<device> fichiers
Je pense que la façon la plus simple de commencer à répondre à votre question est avec quel /dev/<device> les fichiers sont. 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 la 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 Unix.
Lorsque vous branchez ce disque dur (ou lorsque le système le détecte au démarrage), un fichier de périphérique sera créé dans le répertoire /dev répertoire - généralement appelé soit /dev/sd* ou /dev/hd* (selon le contrôleur utilisé pour connecter le lecteur) - le * est une lettre. Les octets du fichier de périphérique sont essentiellement mappés de manière linéaire sur les 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 telles que les MBR et les GPT. Une fois le fichier de périphérique initial créé, il sera lu pour déterminer s'il a une table de partition. Si tel est le cas, des fichiers de périphérique représentant ces partitions seront créés. Donc, en supposant que le fichier de périphérique d'origine s'appelait /dev/sda , un fichier de périphérique appelé /dev/sda1 sera créé (représentant la première partition au format ext4), ainsi qu'un /dev/sda2 device (représentant la deuxième partition LVM). Celles-ci sont mappées de manière linéaire sur leurs partitions respectives de la même manière que le lecteur entier - c'est-à-dire si vous utilisez un outil pour (par exemple) écrire au début de /dev/sda2 , les données écrites seront écrites physiquement au début de la deuxième partition, qui est en fait le milieu de tout le disque, car c'est là que commence la deuxième partition.
Blocs et secteurs
C'est un moment propice pour parler de blocs et de secteurs :ce ne sont que des mesures d'espace sur un disque physique, rien de plus (du moins si j'ai bien compris). 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 les 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 réside le système de fichiers (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 elle 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 ls ou un tree . L'arborescence des répertoires indique quels fichiers et répertoires sont les enfants de quels autres répertoires. La relation fichier/répertoire parent-enfant forme l'arborescence de répertoires UNIX telle que nous la connaissons.
Mais l'arborescence des 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 telles que l'endroit où les éléments d'un fichier sont physiquement stockés sur le disque. Un inode en lui-même est simplement « un fichier » sans nom; un inode est associé à un nom via l'arborescence des répertoires. Voir aussi Qu'est-ce qu'un superbloc, un inode, un dentry et un fichier ?
Jusqu'à présent, nous avons l'explication suivante :/dev/sd* mappage des fichiers sur les disques durs, /dev/sd*# les fichiers correspondent au numéro de partition # sur /dev/sd* . Un système de fichiers est une structure de données sur disque qui conserve une trace 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 une trace des données en blocs. Habituellement, 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 causer des problèmes où 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 d'appareils
La dernière pièce du puzzle est un module très important du noyau Linux appelé device mapper (chargez-le avec modprobe dm ). Le mappeur de périphérique vous permet essentiellement de créer un autre fichier de périphérique dans le /dev/mapper annuaire. Ce fichier de périphérique est ensuite mappé à une autre source de données, éventuellement transformé au cours du processus. L'exemple le plus simple est la lecture d'une partie d'un fichier.
Supposons que vous disposiez d'une image de disque complète, complète avec la table de partition. Vous devez lire les données de l'une des partitions de l'image, mais vous ne pouvez pas accéder à juste cette partition, puisqu'il s'agit d'une image de disque complet, au lieu d'une image à partition unique. La solution consiste à trouver où se trouve votre partition dans l'image, puis à créer un nouveau mappage de fichier de périphérique 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 requête - une lecture, une écriture, etc. - commence à une extrémité de la bande transporteuse, sur un fichier de périphérique créé avec le mappeur de périphérique. La demande passe ensuite par la transformation du mappeur de périphérique vers le fichier source. Dans l'exemple ci-dessus, ce fichier source est un fichier normal, diskimage.img . Voici le diagramme :
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érique a de petits outils (+ s) pour manipuler la demande de lecture lors de son déplacement sur le tapis roulant.
Maintenant, je n'ai pas particulièrement envie de copier ce diagramme et de le modifier pour LVM, mais fondamentalement, la partie transformation peut être n'importe quoi - pas seulement déplacer la plage d'octets vers l'avant. Voici comment fonctionne LVM :une étendue physique LVM est la partie de LVM qui se trouve sur le disque et qui garde une trace de l'emplacement des données. Considérez-le comme le système de fichiers de LVM. Dans la métaphore du tapis roulant, une étendue physique est l'un des fichiers source, et la transformation est LVM qui fait son travail, mappant une demande sur un volume logique (qui est l'élément le plus à gauche sur le tapis roulant) 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, alors, est comme une partition, et les volumes logiques sont ce qui a réellement des fichiers de périphérique qui les représentent. Vous placez des systèmes de fichiers et d'autres éléments sur des volumes logiques.
Ce qui est cool avec le mappeur de périphérique, c'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 schémas de chiffrement qui fonctionnent au niveau du fichier - ceux qui utilisent FUSE), et c'est ainsi que fonctionne LVM. Je ne peux pas penser à d'autres exemples pour le moment, mais croyez-moi, le mappeur d'appareils est assez dur à cuire.
Adressage des blocs logiques
Je n'en ai jamais entendu parler, donc je ne peux donner aucune information à ce sujet. J'espère que quelqu'un viendra modifier cette réponse.