Les lecteurs de disque et les périphériques de type lecteur de disque sont «stupides». Vous lui demandez un LBA, il vous rend les 512, 2048 ou 4096 octets qu'il contient; vice versa pour l'écriture.
Une couche de système de fichiers vous permet de dire "Je veux c: \ users \ public \ documents \ quelquechose.doc" et d'effectuer des opérations de streaming sur cela (ouvrir, lire, écrire, rechercher, fermer) - elle se traduit à partir d'emplacements adressables par nom en une série des demandes de lecture / écriture des LBA.
La couche du système de fichiers a donc deux côtés, l'un qui communique avec le périphérique de type lecteur de disque (ou bloc) et l'autre qui communique avec le système d'exploitation. C'est là que la spécificité du système d'exploitation entre en jeu. Habituellement, le côté périphérique de bloc du système de fichiers est un pilote de périphérique et le côté système d'exploitation est une API utilisable par les applications. Mais ce ne sont que des interfaces et n'ont pas vraiment à affecter le fonctionnement sous-jacent de la couche du système de fichiers.
Tous les systèmes de fichiers entraînent l'écriture et la lecture de données supplémentaires en dehors des données de fichier, afin de garder une trace des informations sur les fichiers, c'est-à-dire d'enregistrer les autorisations, les attributs, etc.
Il y a un peu de problème de démarrage avec le poulet - comme les fichiers du système d'exploitation sont stockés sur le système de fichiers, mais comment sont-ils chargés si la couche du système de fichiers n'est pas encore active? Linux résout ce problème avec un disque RAM initial ou en intégrant le code du système de fichiers dans le cadre du noyau. Windows résout ce problème en donnant au chargeur de démarrage Windows la possibilité de lire les partitions FAT et NTFS. Les chargeurs de démarrage peuvent être stupides, comme la plupart des chargeurs de démarrage BIOS classiques qui ne chargent que LBA 0 et l'exécutent et s'attendent à ce que le code soit récupéré par la suite, ou assez intelligent et avec de petites couches de système de fichiers qui leur sont propres, telles que UEFI, U-boot, etc.
LVM n'est pas un système de fichiers. Il prend un ou plusieurs périphériques de bloc et l'abstrait dans un autre périphérique de bloc "virtuel" (dans /dev/mapper
- tout ce qui /dev/mapper
est dans est un périphérique de bloc virtuel). Vous placez un système de fichiers "au-dessus" d'un LVM de la même manière que vous mettriez un système de fichiers "au-dessus" d'une partition. LVM est une autre couche entre un ou plusieurs pilotes de périphérique et le système de fichiers, convertissant les lectures et les écritures en LBA sur le périphérique de bloc virtuel en un ou plusieurs autres périphériques de bloc. Oui, un LVM peut être un périphérique de bloc virtuel et vous pouvez en avoir une cascade.