Pourquoi avons-nous besoin de monter sur Linux?

Je comprends ce qu'est le montage sous Linux et les fichiers de périphérique. Cependant, je ne comprends pas POURQUOI nous devons monter.

Par exemple, comme expliqué dans la réponse acceptée à cette question , utilisez cette commande:

mount /dev/cdrom /media/cdrom

nous montons le lecteur de CD-ROM sur /media/cdromet, éventuellement, pouvons accéder aux fichiers du CD-ROM à l'aide de la commande suivante

ls /media/cdrom

qui listera le contenu du CDROM.

Pourquoi ne pas sauter complètement le montage et procéder comme suit?

ls /dev/cdrom

Et avoir le contenu du CDROM Listé. Je pense que l’une des réponses sera: " C’est ainsi que Linux est conçu ". Mais si oui, alors pourquoi a-t-il été conçu de cette façon? Pourquoi ne pas accéder /dev/cdromdirectement au répertoire? Quel est le but réel du montage?

L'une des raisons est que l'accès au niveau des blocs est un peu plus bas que celui avec lequel lson pourrait travailler. /dev/cdrom, ou dev/sda1votre lecteur de CD-ROM et votre partition 1 de votre disque dur, respectivement, mais ils ne mettent pas en œuvre la norme ISO 9660 / ext4 - ils sont simplement des pointeurs RAW vers ces périphériques appelés fichiers de périphérique .

Une des choses que mount détermine est de savoir comment utiliser cet accès brut - quels modules de logique / pilote / noyau du système de fichiers vont gérer les lectures / écritures, ou traduire ls /mnt/cdromen quels blocs doivent être lus, et comment interpréter le contenu de ceux-ci bloque des choses comme file.txt.

D'autres fois, cet accès de bas niveau peut être suffisant. Je viens de lire et d'écrire sur des ports série, des périphériques USB, des terminaux tty et d'autres périphériques relativement simples. Je n'essaierai jamais de lire / écrire manuellement à partir de / dev / sda1 pour, par exemple, éditer un fichier texte, car je devrais réimplémenter la logique ext4, ce qui peut inclure, entre autres choses: rechercher les inodes du fichier, trouver le stockez des blocs, lisez le bloc complet, effectuez mes modifications, écrivez les blocs complets, puis mettez à jour l'inode (peut-être) ou écrivez tout cela dans le journal - beaucoup trop difficile.

Une façon de voir cela par vous-même est juste de l'essayer:

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devest un répertoire, et vous pouvez cdet lstout ce que vous aimez. /dev/sda1n'est pas un répertoire; c'est un type spécial de fichier qui correspond à ce que le noyau propose comme "descripteur" de ce périphérique.

Voir l'entrée Wikipedia sur les fichiers de périphériques pour un traitement plus approfondi.

En résumé, et pour le dire facilement, le système d’exploitation doit savoir comment accéder aux fichiers de ce périphérique.

mount non seulement "vous donne accès aux fichiers", il indique au système d'exploitation le système de fichiers du lecteur, s'il s'agit d'un accès en lecture seule ou en lecture / écriture, etc.

/dev/cdromest un périphérique de bas niveau, les fonctions du système d’exploitation ne sauraient pas comment y accéder ... imaginez que vous y mettiez un cdrom au format étrange (même un cd audio), comment lsindiquer quels fichiers (le cas échéant) sont présents le cd-rom sans le "monter" d'abord?

Notez que cela se produit automatiquement dans de nombreux systèmes d'exploitation (même Linux sur certaines distributions et interfaces graphiques), mais cela ne signifie pas que d'autres systèmes d'exploitation ne "montent" pas les lecteurs.

Pour la cohérence

Imaginez que vous ayez des partitions sur le premier disque dur de votre système. Par exemple, /dev/sda2. Vous décidez plus tard que le disque n'est pas assez grand, vous en achetez un second et l'ajoutez au système. Tout à coup, cela devient /dev/sdaet votre lecteur actuel devient /dev/sdb. Votre partition est maintenant /dev/sdb2.

Avec votre système proposé, vous devez modifier tous les scripts, applications, paramètres, etc. qui accèdent aux données de votre ancienne partition pour refléter ce changement de nom.

Cependant, le montage vous permet d’utiliser toujours le même point de montage pour ce lecteur renommé. Vous devez modifier /etc/fstabpour indiquer à votre système que (par exemple) /media/backupest maintenant à la /dev/sdb2place, mais il ne s'agit que d'une modification.

Notez que les systèmes modernes sont encore plus faciles. Au lieu de référencer le périphérique en tant que /dev/sda2ou /dev/sdb2, ils ont UUIDS, qui ressemblent c5845b43-fe98-499a-bf31-4eccae14261bou peuvent recevoir des étiquettes plus conviviales telles que celles backupqui peuvent être utilisées pour référencer le périphérique lors du montage. Ainsi, le nom du périphérique ne change pas lors de l'ajout d'un nouveau périphérique, ce qui simplifie encore l'administration:

# mount LABEL="backup" /media/backup

Pour la sécurité

En exigeant le montage d'un périphérique, l'administrateur peut contrôler l'accès à celui-ci. Le périphérique peut être retiré lorsqu'il est démonté, mais pas lorsqu'il est utilisé (sauf si vous souhaitez subir une perte de données). Si vous êtes (étiez) un utilisateur Windows, souvenez-vous de la petite icône verte dans la zone de notification vous indiquant que vous pouvez retirer une clé USB en toute sécurité. C’est Windows qui monte et démonte le manche pour vous. Le principe n’est donc pas uniquement un système Unix / Linux.

Je l'appellerais des raisons historiques. Non pas que les autres réponses soient fausses, mais l'histoire est un peu plus compliquée.

Comparez Windows: Windows a démarré en tant que système d'exploitation mono-ordinateur / mono-utilisateur. Cet ordinateur unique avait probablement un lecteur de disquette et un disque dur, pas de connexion réseau, pas d'USB, rien. (Windows 3.11 disposait de fonctionnalités réseau natives, contrairement à Windows 3.1 .)

Le type de paramètre dans lequel Windows était né était si simple qu'il ne fallait pas en avoir envie: il suffit de tout monter (les deux périphériques) automatiquement à chaque fois, il n'y a pas beaucoup de choses qui pourraient mal se passer.

Au contraire, Unix était conçu pour fonctionner sur des réseaux de serveurs avec plusieurs utilisateurs dès le début.

L'une des décisions de conception d'Unix était que le système de fichiers devait apparaître comme une entité uniforme unique pour les utilisateurs finaux, quel que soit le nombre d'ordinateurs sur lesquels les disques physiques étaient dispersés, quel que soit le type de disque et les dizaines d'ordinateurs. l'utilisateur y accéderait. Le chemin logique vers les fichiers de l'utilisateur resterait le même, même si l'emplacement physique de ces fichiers avait changé du jour au lendemain, par exemple en raison de la maintenance du serveur.

Ils isolaient le système de fichiers logique, les chemins d'accès aux fichiers, des périphériques physiques qui stockaient ces fichiers. Supposons que le serveur A héberge normalement / home, mais que le serveur A nécessite une maintenance: démontez simplement le serveur A et montez le serveur de sauvegarde B sur / home à la place, sans que les administrateurs s'en aperçoivent.
(Contrairement à la convention de Windows consistant à donner des noms différents à différents périphériques physiques - C :, D :, etc. - ce qui va à l’encontre de la transparence recherchée par Unix.)

Dans ce genre de contexte, vous ne pouvez pas tout mettre en place, bon gré mal gré,

Dans un grand réseau, les disques individuels et les ordinateurs sont constamment hors service. Les administrateurs doivent avoir la possibilité de dire ce qui est monté, où et quand, par exemple pour arrêter de manière contrôlée un ordinateur, tandis qu'un autre ordinateur prend en charge l'hébergement des mêmes fichiers de manière transparente.

C'est pourquoi, d'un point de vue historique, Windows et Unix provenaient d'horizons différents. Vous pourriez appeler cela une différence culturelle, si vous aimez:

• Unix est né dans un environnement où l'administrateur devait contrôler le montage. parmi les dizaines de périphériques de stockage présents sur le réseau, l’administrateur doit décider de ce qui est monté, où et quand.
• Windows est né dans un environnement où il n'y avait pas d'administrateur et seulement deux périphériques de stockage, et l'utilisateur saurait probablement si leur fichier se trouvait sur la disquette ou sur le disque dur.
• (Linux est né comme système d'exploitation mono-ordinateur, bien sûr, mais il a également été explicitement conçu dès le début pour imiter Unix aussi fidèlement que possible sur un ordinateur personnel.)

Plus récemment, les systèmes d'exploitation se sont rapprochés:

• Linux a ajouté plus de choses sur un seul ordinateur, un seul utilisateur (comme le montage automatique); comme il est devenu fréquemment utilisé dans les paramètres d'un seul ordinateur.
• Windows a ajouté plus de sécurité, de mise en réseau, de support pour plusieurs utilisateurs, etc .; la mise en réseau devenant de plus en plus omniprésente, Microsoft a également commencé à créer un système d'exploitation pour serveurs.

Mais il est toujours facile de dire que les deux sont le résultat de traditions différentes.

L'agencement actuel présente plusieurs avantages. Ils peuvent être regroupés en avantages de bloquer des fichiers spéciaux et avantages de points de montage.

Les fichiers spéciaux sont des fichiers qui représentent des périphériques. L'une des idées sur lesquelles Unix a été construit est que tout est un fichier. Cela simplifie beaucoup de choses, par exemple, l’interaction de l’utilisateur se limite à la lecture et à l’écriture de fichiers sur un périphérique tty, qui est un fichier spécial de caractères. de même, rechercher des blocs défectueux, partitionner ou formater un disque ne sont que des opérations sur fichiers. Peu importe que le disque soit au format mfm, ide, scsi, fiberchanel ou autre chose, il s’agit simplement d’un fichier.

Mais d’autre part, vous ne voudrez peut-être pas traiter le disque entier ou la partition uniquement les fichiers, et dans de nombreux cas plus de fichiers que ce qui peut en contenir sur un disque. Nous avons donc des points de montage. Un point de montage vous permet de placer un disque entier (ou une partition) dans un répertoire. À l'époque de Slackware, quand un disque dur de bonne taille faisait quelques centaines de Mo, il était courant d'utiliser le CD en tant que / usr et le disque dur pour /, / usr / local et swap. Ou vous pouvez mettre / sur un lecteur et / home sur un autre.

Maintenant, j'ai remarqué que vous avez mentionné le montage de votre CD sur / media / cdrom, ce qui est pratique pour les ordinateurs dotés d'un seul lecteur de cdrom, mais que se passe-t-il si vous en avez plusieurs? Où devriez-vous monter le second? ou le troisième? ou le quinzième? vous pouvez certainement utiliser / media / cdrom2, etc. Ou vous pouvez le monter sur / src / samba / resources / windows-install, ou sur / var / www, ou à tout autre endroit approprié.

Le titre de la question demande: Pourquoi avons-nous besoin de monter sur Linux?

Une façon d'interpréter cette question: Pourquoi devons-nous émettre des mountcommandes explicites pour rendre les systèmes de fichiers disponibles sous Linux?

La réponse: nous ne le faisons pas.

Vous n'avez pas besoin de monter explicitement les systèmes de fichiers, vous pouvez le faire automatiquement, et les distributions Linux le font déjà pour la plupart des périphériques, à l'instar de Windows et des Mac.

Donc, ce n'est probablement pas ce que vous vouliez demander.

Deuxième interprétation: pourquoi avons-nous parfois besoin d’émettre des mountcommandes explicites pour rendre les systèmes de fichiers disponibles sous Linux? Pourquoi ne pas faire en sorte que le système d'exploitation le fasse toujours pour nous et le cache à l'utilisateur?

Voici la question que je lis dans le texte de la question, lorsque vous posez la question suivante:

Pourquoi ne pas sauter complètement le montage et procéder comme suit

ls /dev/cdrom

et le contenu du CD-ROM est-il répertorié?

Vraisemblablement, vous voulez dire: pourquoi ne pas simplement avoir cette commande faire ce

ls /media/cdrom

fait maintenant?

Eh bien, dans ce cas, /dev/cdromserait une arborescence de répertoires, pas un fichier de périphérique. Donc, votre vraie question semble être: pourquoi un fichier de périphérique en premier lieu?

J'aimerais ajouter une réponse à celles déjà données.

Pourquoi les utilisateurs peuvent-ils voir les fichiers de l'appareil?

Chaque fois que vous utilisez un CD-ROM ou tout autre périphérique qui stocke des fichiers, un logiciel est utilisé pour interpréter tout ce qui se trouve sur votre CD-ROM comme une arborescence de répertoires. Il est appelé chaque fois que vous utilisez lsou tout autre type de commande ou d’application qui accède aux fichiers de votre CD-ROM. Ce logiciel est le pilote de système de fichiers du système de fichiers utilisé pour écrire les fichiers sur votre CD-ROM. Chaque fois que vous répertoriez, lisez ou écrivez des fichiers sur un système de fichiers, ce logiciel a pour tâche de vous assurer que les opérations de lecture et d'écriture de bas niveau correspondantes sont effectuées sur le périphérique en question. Chaque fois que vous êtes mountun système de fichiers, vous indiquez au système le pilote de système de fichiers à utiliser pour le périphérique. Que vous le fassiez explicitement avec unmountcommande, ou laissez le système d'exploitation le faire automatiquement, cela devra être fait, et bien sûr, le logiciel du pilote du système de fichiers devra être présent en premier lieu.

Comment un pilote de système de fichiers fait-il son travail? La réponse: il le fait en lisant et en écrivant dans le fichier de périphérique. Pourquoi? La réponse, comme vous l'avez déjà dit: Unix a été conçu de cette façon. Sous Unix, les fichiers de périphérique sont l'abstraction commune de bas niveau pour les périphériques. Le logiciel vraiment spécifique à un périphérique (le pilote de périphérique) pour un périphérique particulier est supposé implémenter l'ouverture, la fermeture, la lecture et l'écriture sur le périphérique en tant qu'opérations sur le fichier de périphérique. Ainsi, les logiciels de niveau supérieur (tels que les pilotes de système de fichiers) n'ont pas besoin d'en savoir autant sur le fonctionnement interne des périphériques individuels. Les pilotes de périphérique de bas niveau et les pilotes de système de fichiers peuvent être écrits séparément, par différentes personnes, dans la mesure où ils conviennent d'une manière commune de se connecter, ce à quoi servent les fichiers de périphérique.

Les pilotes de système de fichiers ont donc besoin des fichiers de périphérique.

Mais pourquoi avons-nous, utilisateurs ordinaires, accès aux fichiers de l'appareil? La réponse est qu'Unix a été conçu pour être utilisé par les programmeurs de système d'exploitation. Il a été conçu pour permettre à ses utilisateurs d'écrire des pilotes de périphérique et des pilotes de système de fichiers. C'est en fait comment ils sont écrits.

Il en va de même pour Linux: vous pouvez écrire votre propre pilote de système de fichiers (ou pilote de périphérique), l'installer, puis l'utiliser. Cela rend Linux (ou toute autre variante d'Unix) facilement extensible (et c'est en fait la raison pour laquelle Linux a été démarré): lorsqu'un nouveau matériel arrive sur le marché, ou qu'une nouvelle méthode plus intelligente d'implémentation d'un système de fichiers est conçue , quelqu'un peut écrire le code pour le prendre en charge, le faire fonctionner et le contribuer à Linux.

Les fichiers de périphérique facilitent cela.

De nombreux moteurs de base de données peuvent travailler directement avec des disques ou des partitions bruts. Par exemple, MySQL:

http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html

Cela évite la surcharge liée aux pilotes de système de fichiers, alors que tout ce dont le moteur de base de données a vraiment besoin est un fichier énorme qui remplit le disque.

Car /dev/cdromest un périphérique, alors /media/cdromqu'un système de fichiers . Vous devez monter le premier sur le dernier pour pouvoir accéder aux fichiers du CD-ROM.

Votre système d'exploitation monte déjà automatiquement les systèmes de fichiers racine et utilisateur à partir de votre disque dur physique, lorsque vous démarrez votre ordinateur. Cela ne fait qu'ajouter plus de systèmes de fichiers à utiliser.

Tous les systèmes d'exploitation le font - cependant, certains (tels que Windows, lorsqu'il monte un CD-ROM sur D:) le font de manière transparente. Linux vous laisse le soin de mieux contrôler le processus.

Cela est dû au fait qu’il existe, avec de nombreux supports pour les interfaces utilisateur de bureau et d’ordinateur portable, une ambiguïté sur ce qu’il faut faire lorsque le support est inséré, car l’intuition de l’utilisateur est que l’insertion du disque dans le boîtier physique avec lequel l’utilisateur interagit n’est pas différente, par exemple. , en l'insérant dans un périphérique à côté de l'ordinateur disposant d'une connexion réseau.

Ainsi, au sens fondamental, l’interface utilisateur pour les médias doit traiter les deux types d’événements de montage potentiels de la même manière, et il n’existe aucun moyen efficace pour les ordinateurs de gérer les montages réseau de manière aussi intuitive que possible pour les montages réseau avec d’autres interfaces utilisateur, tels que les smartphones, les tablettes et les ordinateurs portables, pour lesquels il est impossible d'insérer un support physique dans les appareils. (Notez à quel point l'interface de l'iPhone est horrible pour changer de carte SIM, l'un des types de supports physiques que les périphériques iOS ont insérés.

Notez également que d'autres approches populaires d'interface utilisateur pour ce type de boîtier physique (par exemple, Windows 98, Windows 8, Mac OS X version 10.2 (Jaguar) et Mac OS X version 10.9 (Mavericks)) rencontrent les mêmes problèmes. et utilisez des boîtes de dialogue graphiques supplémentaires pour résoudre le problème (par exemple, Windows 8 est généralement configuré pour indiquer à chaque nouveau CD inséré s'il doit être monté en tant que système de fichiers, support musical ou, le cas échéant, collection de vidéos MP4). ) Il n’ya aucune raison pour qu’aucune de ces boîtes de dialogue utilisateur ne puisse être utilisée avec Linux ou d’autres UNIX.