Pourquoi devons-nous monter sur Linux?
Je comprends ce qu'est le montage sous Linux et je comprends les fichiers de périphérique. Cependant, je ne comprends pas POURQUOI nous devons monter.
Par exemple, comme expliqué dans le réponse acceptée à cette question , en utilisant cette commande:
mount /dev/cdrom /media/cdrom
nous montons le périphérique CDROM sur /media/cdrom et éventuellement accéder aux fichiers du CD-ROM avec la commande suivante
ls /media/cdrom
qui listera le contenu du CD-ROM.
Pourquoi ne pas sauter complètement le montage et procéder comme suit?
ls /dev/cdrom
Et avoir le contenu du CDROM listé. Je m'attends à ce que l'une des réponses soit: " Voici comment Linux est conçu ". Mais si oui, alors pourquoi a-t-il été conçu de cette façon? Pourquoi ne pas accéder au /dev/cdrom répertoire directement? Quel est le véritable objectif du montage?
L'une des raisons est que l'accès au niveau du bloc est un niveau un peu inférieur à ce que ls pourrait utiliser. /dev/cdrom, ou dev/sda1 peut être votre CD ROM et partition 1 de votre disque dur, respectivement, mais ils n'implémentent pas ISO 9660/ext4 - ce ne sont que des pointeurs RAW vers ces périphériques appelés - Fichiers de périphérique .
Le montage détermine entre autres 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/cdrom dans quels blocs doivent être lus, et comment interpréter le contenu de ces blocs dans 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'essaierais jamais de lire/écrire manuellement depuis/dev/sda1 pour, disons, éditer un fichier texte, car je devrais fondamentalement réimplémenter la logique ext4, qui peut inclure, entre autres: rechercher les inodes de fichier, trouver le des blocs de stockage, lire le bloc complet, effectuer mes modifications, écrire les blocs complets, puis mettre à jour l'inode (peut-être), ou plutôt écrire tout cela dans le journal - beaucoup trop difficile.
Une façon de voir par vous-même est de l'essayer:
[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory
/dev est un répertoire, et vous pouvez cd et ls tout ce que vous voulez. /dev/sda1 n'est pas un répertoire; c'est un type de fichier spécial qui est ce que le noyau offre comme "poignée" à ce périphérique.
Voir l'entrée wikipedia sur les fichiers de périphérique pour un traitement plus approfondi.
Fondamentalement, et pour le dire facilement, le système d'exploitation doit savoir comment accéder aux fichiers sur cet appareil.
mount ce n'est pas seulement "vous donner accès aux fichiers", c'est dire au système d'exploitation le système de fichiers du disque, s'il est en lecture seule ou en lecture/écriture, etc.
/dev/cdrom est un appareil 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 bizarre (même un CD audio), comment ls dirait lequel les fichiers (le cas échéant) sont-ils sur le cd-rom sans le "monter" au préalable?
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 disques.
Par souci de cohérence
Imaginez que vous avez des partitions sur le premier disque dur de votre système. Par exemple, /dev/sda2. Vous décidez plus tard que le lecteur n'est pas assez grand, vous en achetez un deuxième et l'ajoutez au système. Tout d'un coup, cela devient /dev/sda et votre lecteur actuel devient /dev/sdb. Votre partition est maintenant /dev/sdb2.
En utilisant 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/fstab pour indiquer à votre système que (par exemple) /media/backup est maintenant /dev/sdb2 à la place, mais ce n'est qu'une seule modification.
Notez que les systèmes modernes sont encore plus faciles. Au lieu de référencer le périphérique comme /dev/sda2 ou /dev/sdb2, ils ont UUIDS, qui ressemble à c5845b43-fe98-499a-bf31-4eccae14261b ou peut recevoir des étiquettes plus conviviales telles que backup qui peuvent être utilisées pour référencer l'appareil lors du montage. De cette façon, le nom de l'appareil ne change pas lors de l'ajout d'un nouvel appareil, ce qui rend l'administration encore plus simple:
# mount LABEL="backup" /media/backup
Pour votre sécurité
En exigeant le montage d'un périphérique, l'administrateur peut contrôler l'accès au périphérique. L'appareil peut être retiré lorsqu'il n'est pas monté, mais pas lorsqu'il est utilisé (sauf si vous souhaitez subir une perte de données). Si vous êtes (étiez) un utilisateur Windows, rappelez-vous la petite icône verte dans la zone de notification qui vous indique qu'il est sûr de retirer une clé USB? C'est le montage et le démontage de Windows pour vous. Le principe n'est donc pas uniquement un Unix/Linux.
J'appellerais cela des raisons historiques. Non pas que les autres réponses soient fausses, mais il y a un peu plus dans l'histoire.
Comparez Windows: Windows a démarré comme un système d'exploitation à un seul ordinateur et à un seul 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 avait des capacités de mise en réseau natives; Windows 3.1 n'en avait pas .)
Le type de configuration dans lequel Windows est né était si simple qu'il n'y avait pas besoin d'être sophistiqué: montez simplement tout (les deux appareils) automatiquement à chaque fois, il n'y a pas (pas beaucoup) de choses qui pourraient mal tourner.
En revanche, Unix a été 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 Unix était que le système de fichiers devrait apparaître comme une entité uniforme unique pour les utilisateurs finaux, quel que soit le nombre d'ordinateurs sur lesquels les disques physiques étaient répartis, quel que soit le type de disque et quel que soit le nombre de 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 faisaient abstraction du système de fichiers logique, des chemins d'accès aux fichiers, des périphériques physiques qui stockaient ces fichiers. Supposons que le serveur A héberge/héberge normalement, 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, et personne en dehors des administrateurs ne le remarquera même.
(Contrairement à la convention de Windows de donner des noms différents à différents périphériques physiques - C :, D :, etc. - qui va à l'encontre de la transparence qu'Unix recherchait.)
Dans ce genre de cadre, vous ne pouvez pas tout monter à vue de bon gré,
Dans un grand réseau, les disques et ordinateurs individuels sont constamment hors service. Les administrateurs doivent pouvoir dire ce qui est monté où et quand, par ex. pour effectuer un arrêt contrôlé d'un ordinateur pendant qu'un autre ordinateur prend en charge de manière transparente l'hébergement des mêmes fichiers.
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 avait besoin de contrôler le montage; des dizaines de périphériques de stockage sur le réseau, l'administrateur doit décider 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 savait probablement si son fichier se trouvait sur la disquette ou sur le disque dur.
- (Linux est né comme un système d'exploitation à ordinateur unique, bien sûr, mais il a également été explicitement conçu dès le départ pour imiter Unix aussi étroitement que possible sur un ordinateur personnel.)
Plus récemment, les OS se sont rapprochés les uns des autres:
- Linux a ajouté plus de trucs pour un seul ordinateur et un seul utilisateur (comme le montage automatique); car 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 prise en charge de plusieurs utilisateurs, etc.; alors que la mise en réseau est devenue plus omniprésente et Microsoft a également commencé à créer un système d'exploitation pour les serveurs.
Mais il est toujours facile de dire que les deux sont le résultat de traditions différentes.
Le titre de la question demande: Pourquoi devons-nous monter sur Linux?
Une façon d'interpréter cette question: Pourquoi devons-nous émettre des commandes mount explicites pour rendre les systèmes de fichiers disponibles sur Linux?
La réponse: non.
Vous n'avez pas besoin de monter les systèmes de fichiers de manière explicite, vous pouvez faire en sorte que cela se fasse automatiquement, et les distributions Linux le font déjà pour la plupart des appareils, tout comme Windows et Mac.
Ce n'est donc probablement pas ce que vous vouliez demander.
Une deuxième interprétation: Pourquoi avons-nous parfois besoin d'émettre des commandes explicites mount pour rendre les systèmes de fichiers disponibles sur Linux? Pourquoi ne pas faire le système d'exploitation toujours le faire pour nous, et le cacher à l'utilisateur?
C'est la question que je lis dans le texte de la question, lorsque vous demandez:
Pourquoi ne pas sauter complètement le montage et procédez comme suit
ls /dev/cdrom
et le contenu du CD-ROM est-il répertorié?
Vraisemblablement, vous voulez dire: pourquoi ne pas simplement faire faire cette commande
ls /media/cdrom
fait maintenant?
Eh bien, dans ce cas, /dev/cdrom serait une arborescence de répertoires, pas un fichier de périphérique. Votre vraie question semble donc être: pourquoi avoir un fichier de périphérique en premier lieu?
Je voudrais ajouter une réponse à celles déjà données.
Pourquoi les utilisateurs voient-ils 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é qui interprète tout ce qui se trouve sur votre CD-ROM comme une arborescence de répertoires de fichiers. Il est invoqué chaque fois que vous utilisez ls ou tout autre type de commande ou d'application qui accède aux fichiers de votre CD-ROM. Ce logiciel est le pilote du système de fichiers pour le système de fichiers particulier 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, c'est le travail de ce logiciel de s'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 mount un système de fichiers, vous dites au système quel pilote de système de fichiers utiliser pour le périphérique. Que vous le fassiez explicitement avec une commande mount ou que vous le laissiez au système d'exploitation se faire automatiquement, cela devra être fait, et bien sûr, le logiciel du pilote du système de fichiers devra être là 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 l'appareil. 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 de bas niveau courante pour les périphériques. Le logiciel vraiment spécifique au périphérique (le pilote de périphérique) pour un périphérique particulier est censé implémenter l'ouverture, la fermeture, la lecture et l'écriture sur le périphérique en tant qu'opérations sur le fichier du périphérique. De cette façon, les logiciels de niveau supérieur (comme un pilote 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, à condition qu'ils s'accordent sur une manière commune de s'interfacer les uns avec les autres, et c'est à cela que servent les fichiers de périphérique.
Les pilotes du système de fichiers ont donc besoin des fichiers du périphérique.
Mais pourquoi, utilisateurs ordinaires, pouvons-nous voir les fichiers de l'appareil? La réponse est qu'Unix a été conçu pour être utilisé par les programmeurs de systèmes 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 ainsi qu'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é lancé): quand un nouveau matériel vient sur le marché, ou une nouvelle façon plus intelligente d'implémenter 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 l'appareil facilitent la tâche.
L'arrangement actuel présente plusieurs avantages. Ils peuvent être regroupés en avantages des fichiers spéciaux de bloc et avantages des 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 rend beaucoup de choses simples, par exemple, l'interaction utilisateur n'est que 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, la vérification des blocs défectueux, le partitionnement ou le formatage d'un disque ne sont que des opérations sur les fichiers. Il n'a pas d'importance si le disque est mfm, ide, scsi, fiberchanel ou autre chose, c'est juste un fichier.
Mais d'un autre côté, il se peut que vous ne souhaitiez pas traiter l'intégralité du disque ou de la partition uniquement les fichiers, et dans de nombreux cas, plus de fichiers que ne peut en contenir un disque. Nous avons donc des points de montage. Un point de montage vous permet de placer un disque entier (ou une partition) sur un répertoire. À l'époque de Slackware, lorsqu'un disque dur de bonne taille mesurait quelques centaines de Mo, il était courant d'utiliser le CD comme/usr et le disque dur pour /,/usr/local et de permuter. 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 avec un seul lecteur de cdrom, mais que faire si vous en avez plusieurs? où devez-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/var/www, ou partout où cela est logique de le faire.
De nombreux moteurs de base de données peuvent fonctionner directement avec des disques bruts ou des partitions. Par exemple, MySQL:
http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html
Cela évite les frais généraux liés aux pilotes de système de fichiers, lorsque tout ce dont le moteur de base de données a réellement besoin est un énorme fichier qui remplit le disque.
Parce que /dev/cdrom est un appareil, tandis que /media/cdrom est un système de fichiers. Vous devez monter le premier sur le second afin d'accéder aux fichiers sur le CD-ROM.
Votre système d'exploitation monte déjà automatiquement les systèmes de fichiers racine et utilisateur à partir de votre périphérique de disque dur physique, lorsque vous démarrez votre ordinateur. Il s'agit simplement d'ajouter plus de systèmes de fichiers à utiliser.
Tous les systèmes d'exploitation le font - cependant, certains (comme Windows, quand il monte un CD-ROM sur D:) faites-le de manière transparente. Linux vous laisse le soin de contrôler davantage le processus.
Il le fait parce qu'il y a, 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 la boîte physique avec laquelle 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, dans le 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'y a pas de bon moyen pour les ordinateurs de gérer les montages réseau de manière aussi intuitive que pour les montages réseau avec d'autres interfaces utilisateur sur les ordinateurs, tels que les smartphones, les tablettes et les ordinateurs portables, qui n'ont pas la possibilité d'insérer des supports physiques dans les appareils. (Notez à quel point l'interface iPhone est horrible pour changer de carte SIM, le seul type de support physique que les appareils iOS y ont inséré.
Notez également que d'autres approches courantes des interfaces utilisateur pour ce type de boîtier physique (par exemple, Windows 98, Windows 8, Mac OS X v10.2 (Jaguar) et Mac OS X v10.9 (Mavericks)) rencontrent les mêmes problèmes et utilisez des boîtes de dialogue GUI supplémentaires pour trier la confusion potentielle (par exemple, Windows 8 est généralement configuré pour demander à 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'y a aucune raison pour laquelle aucune de ces boîtes de dialogue utilisateur ne peut être utilisée avec Linux ou d'autres UNIX.