Difficulté à comprendre le concept de montage


13

Après avoir lu les deux Que signifie monter un périphérique sous Linux? et comprendre "monter" comme un concept dans le système d'exploitation , j'ai un problème où il est dit que

Tout stockage accessible doit avoir un emplacement associé dans cette arborescence de répertoires unique. Ceci est différent de Windows où (dans la syntaxe la plus courante pour les chemins de fichiers), il existe une arborescence de répertoires par composant de stockage (lecteur). Le montage consiste à associer un périphérique de stockage à un emplacement particulier dans l'arborescence de répertoires.

Mais il existe déjà un emplacement accessible, par exemple un lecteur de cdrom sous / dev / cdrom, qui vient évidemment dans la hiérarchie des répertoires. Alors pourquoi la nécessité de créer un "point de montage" séparé sous / media / cdrom? Pourquoi l'accès direct à partir de / dev / cdrom est rendu impossible? J'ai entendu dire que les fichiers de noeud de périphérique sont exactement comme les fichiers ordinaires. Et leur lire et leur écrire est comme des fichiers ordinaires. Cela signifie-t-il que le système de fichiers du cdrom n'est pas disponible si nous y accédons depuis / dev / cdrom. Et la hiérarchie du système de fichiers (à l'intérieur du cdrom) "prend vie" lorsque nous la "montons"?

Réponses:


11

Vous pouvez lire ou écrire / dev / cdrom (par exemple, en utilisant ddou cat) mais lorsque vous faites cela, vous ne faites que lire ou écrire les octets bruts du périphérique. Cela peut être utile dans diverses circonstances (comme le clonage d'une partition), mais en général, nous voulons voir les répertoires et les fichiers stockés sur l'appareil.

Lorsque vous montez un périphérique, vous dites essentiellement au noyau d'utiliser une couche de logiciel (le pilote du système de fichiers) pour traduire ces octets bruts en un véritable système de fichiers. Ainsi, le montage d'un périphérique associe le système de fichiers sur ce périphérique à la hiérarchie de répertoires.


8

Je pense à ce sujet de la manière suivante: mountest un outil qui indique au système d'interpréter le contenu de certains fichiers comme des arborescences de répertoires.

  • Le système de fichiers a des répertoires et des fichiers, et chaque fichier est une étiquette pour une chaîne d'octets.
  • /dev/cdrom est un fichier, il représente la chaîne d'octets stockée sur le CD.
  • Vous pouvez lire directement cette très longue chaîne, mais ce n'est pas très pratique, sauf à des fins spéciales (par exemple, créer une image disque complète).
  • Cette longue chaîne a une structure interne supplémentaire: elle contient un système de fichiers, qui contient des informations sur les répertoires et les fichiers qui sont stockés et où dans cette très longue chaîne.
  • En utilisant mount -t iso9660 /dev/cdrom /media/cdrom, vous dites au système: "prenez cette très longue chaîne d'octets que vous avez /dev/cdromdedans, interprétez-la comme une arborescence de répertoires au format iso9660, et permettez-moi d'y accéder sous l'emplacement /media/cdrom".
  • En fait, cela fonctionne également pour les fichiers standard. Vous pouvez créer un fichier standard contenant une image disque, puis l'utiliser mountpour y accéder. Essaye ça:
dd if = / dev / zero of = fs-image bs = 1M count = 50
mke2fs fs-image
sudo mount fs-image / some / mount / point

(les deux premières commandes ne sont requises que la première fois, lors de la préparation du fichier image.)


Pourquoi en aviez-vous besoin mke2fs?
ADTC

Pour créer un système de fichiers ext2 vide à l'intérieur du fichier image. Un système de fichiers vide n'est pas entièrement composé de zéros - il a des métadonnées et des structures fixes, tout comme un document Word ou LibreOffice vide a une taille différente de zéro et contient par exemple des informations sur la police par défaut et la taille de la page.
Krzysztof Kosiński

Oh OK, c'est une action potentiellement destructrice. Vous suggérons de mentionner que cette commande est destinée à la première initialisation uniquement. :)
ADTC

5

/dev/cdromfait référence à un fichier de périphérique . Ce n'est pas le contenu du disque que vous souhaitez insérer dans votre lecteur optique, mais plutôt une référence au peu de matériel (et probablement de pilotes logiciels) que vous pourriez appeler pour vous le montrer. Lorsque vous accédez mount /dev/cdromà un chemin dans votre arborescence, vous attachez son contenu à votre système de fichiers .

Le fait est que je ne peux pas vraiment penser à une autre façon de le faire. Même sous Windows - bien que ce ne soit pas aussi apparent - il y a toujours l'abstraction du système de fichiers pour \\?\volumename\. Il m'a fallu une minute pour me rappeler à quoi cela ressemblait, et j'ai trouvé cela sur Google :

... le nom du volume n'est qu'un lien symbolique qui renvoie à un véritable périphérique de volume, généralement sous la forme de \Device\HarddiskVolume23. Il existe un autre exemple d'un périphérique MS-DOS qui est la lettre de lecteur. Si votre volume a la lettre de lecteur C:, vous aurez alors un lien symbolique appelé \\?\C: qui pointe vers un vrai volume au \Device\HarddiskVolumeXXformat.

Et donc peut-être que ce n'est pas si différent - bien que je dirais moins compliqué - c'est juste plus évident , je pense. Ce n'est pas un seul et même système, mais ils ne sont pas fondamentalement différents non plus.

La distinction probablement la plus importante entre /dev/deviceet /path/to/its/mountest que sur ce dernier chemin un système de fichiers - un peu de logiciel destiné à gérer les données de manière organisée - interprète le contenu du premier. Vous ne pouvez pas simplement lire un disque - quelqu'un doit vous le lire. Le système de fichiers interprète le contenu de l'appareil.


C'est quelque peu trompeur. Si vous ouvrez /dev/cdromdans un éditeur hexadécimal, il contient en fait le contenu brut du CD-ROM. En utilisant, mountvous dites simplement au système d'exploitation d'interpréter ces contenus comme une arborescence de répertoires.
Krzysztof Kosiński

0

En plus des éléments mentionnés ci-dessus, un pilote ou un autre programme peut mettre en cache les données d'un périphérique. Sur un périphérique en lecture-écriture, tel qu'un disque dur ou une clé USB, les données écrites sur le périphérique peuvent ne pas encore avoir été écrites. Les systèmes de fichiers de journalisation peuvent également nécessiter de vider le journal avant qu'il ne voit plus le périphérique. Ensuite, vous avez des systèmes de fichiers qui superposent d'autres systèmes de fichiers, tels que cryptfs, qui ont besoin de savoir quand le système de fichiers sous-jacent n'est plus disponible.

Certes, pour un périphérique en lecture seule, cela a moins de sens, mais cela s'applique toujours.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.