Pourquoi le montage se produit-il sur un répertoire existant?

Un répertoire existant est nécessaire en tant que point de montage .

$ ls
$ sudo mount /dev/sdb2 ./datadisk
mount: mount point ./datadisk does not exist
$ mkdir datadisk
$ sudo mount /dev/sdb2 ./datadisk
$

Je trouve cela déroutant car il recouvre le contenu existant du répertoire. Il existe deux contenus possibles du répertoire du point de montage qui peuvent être modifiés de manière inattendue (pour un utilisateur qui n'effectue pas le montage).

Pourquoi ne se mountpasse- t-il pas dans un répertoire nouvellement créé? C'est ainsi que les systèmes d'exploitation graphiques affichent les supports amovibles. Il serait clair si le répertoire est monté (existe) ou non monté (n'existe pas). Je suis presque sûr qu'il y a une bonne raison mais je n'ai pas encore réussi à le découvrir.

Il s’agit d’un détail de mise en oeuvre qui a filtré.

Dans un système UNIX, chaque répertoire est constitué d'une liste de noms mappés sur des numéros d' inode . Un inode contient des métadonnées qui indiquent au système s'il s'agit d'un fichier, d'un répertoire, d'un périphérique spécial, d'un canal nommé, etc. S'il s'agit d'un fichier ou d'un répertoire, il indique également au système où trouver le contenu du fichier ou du répertoire sur le disque. La plupart des inodes sont des fichiers ou des répertoires. L' -ioption to lslistera les numéros d'inode.

Monter un système de fichiers prend un inode de répertoire et définit un indicateur sur la copie en mémoire du noyau pour dire "réellement, lorsque vous recherchez le contenu de ce répertoire, regardez plutôt cet autre système de fichiers" (voir la diapositive 10 de cette présentation ). C'est relativement facile, car cela modifie un seul élément de données.

Pourquoi ne crée-t-il pas une entrée de répertoire pour vous pointant vers le nouvel inode? Vous pouvez mettre cela en œuvre de deux manières, qui présentent toutes deux des inconvénients. L'une consiste à écrire physiquement un nouveau répertoire dans le système de fichiers - mais cela échoue si le système de fichiers est en lecture seule! L'autre consiste à ajouter à chaque processus de liste de répertoires une liste d'éléments "supplémentaires" qui ne sont pas réellement présents. Cela est fastidieux et risque potentiellement d’entraîner une petite perte de performances lors de chaque opération de fichier.

Si vous souhaitez créer des points de montage créés dynamiquement, le automountsystème peut le faire. Spéciaux non-systèmes de fichiers disque peuvent également créer des répertoires à volonté, par exemple proc, sys, devfset ainsi de suite.

Éditer: voir aussi la réponse à Que se passe-t-il lorsque vous «montez» sur un dossier existant avec du contenu?

Si mount(2) nécessaire la création d'un nouveau répertoire pour être le point de montage, on ne pouvait pas monter quoi que ce soit dans un système de fichiers en lecture seule. Ce serait stupide, alors nous pouvons l'exclure.

Si mount créait éventuellement un nouveau répertoire comme point de montage, ce serait étrange. Ce n'est pas comme si le montage / démontage se produisait tout le temps, donc ajouter une logique supplémentaire dans le noyau pour effectuer ces deux étapes avec un seul appel système ne constituerait pas une accélération importante. Il suffit de laisser à l’espace utilisateur le pouvoir de faire un mkdir(2)appel système s’il le souhaite. La réponse de Dmitry indique qu'avoir mount(2)fait les deux choses le rendrait non atomique. Et vous voulez un argument supplémentaire pour mount(2)avec des drapeaux de mode comme open(2)prend, pour O_CREAT, O_EXCLetc. Il serait tout simplement ridicule par rapport à laisser l'espace utilisateur le faire.

Ou peut-être demandez-vous si mount(8)(le programme traditionnel qui effectue des mount(2)appels système) le fait? Ce serait possible, mais il y a déjà un très bon mkdir(1)travail, et la conception d'Unix est basée sur de bons petits outils pouvant être combinés. Si vous voulez un outil qui fait les deux, il est facile d'écrire un script shell pour le construire à partir de deux outils plus simples. (Ou, comme le dit muru, le fait udisksctldéjà, vous n'avez donc pas à l'écrire.) De plus, Linux utilise normalement la syntaxe mount(8)d'util-linux mount -o x-mount.mkdir[=mode]avec sa x-syntaxe pour les options de l'espace utilisateur, plutôt que les options à transmettre au système de fichiers.

Maintenant la question la plus intéressante: pourquoi faut-il un répertoire sur le système de fichiers parent?

Comme le souligne la réponse de pjc50 (aucune relation, même s'il a mes initiales!), L'affichage des points de montage dans les listes de répertoires exigerait un contrôle supplémentaire à chaque passage readdir().

Disposer de points de montage en tant que répertoires dans le répertoire qui les contient (sur le système de fichiers parent) est une bonne astuce. readdir()ne doit pas remarquer que c'est un point de montage du tout. Cela ne se produit que si le point de montage est utilisé comme composant de chemin. La résolution du chemin doit bien sûr vérifier la table de montage pour chaque composant de répertoire d'un chemin.

Monter sur un répertoire existant appelle mountpratiquement atomique: il réussit ou échoue, du moins du point de vue de l'utilisateur. S'il mountdevait créer le point de montage lui-même, il aurait deux points de défaillance, rendant impossible la garantie d'un retour en arrière propre. Imaginez le scénario suivant:

1. mount crée avec succès le point de montage
2. mount tente de monter un nouveau système de fichiers dans ce répertoire, mais échoue
3. mount tente de supprimer le point de montage, mais échoue

Le système finit par avoir un effet secondaire d'échec mount.

En voici un autre:

1. umount démonte avec succès un système de fichiers
2. umount tente de supprimer le point de montage, mais échoue

Maintenant, faut-il umountretourner le succès ou l'échec?

Un autre cas qui peut se produire:

Lorsque vous démarrez, une image de base en lecture seule est chargée dans le répertoire racine. Vous souhaitez donc le remplacer lorsque vous souhaitez créer une racine réelle. Vous pouvez donc imaginer que mount syscall permute simplement le ropoint de montage rw.

Ici, imaginons que vous ayez un problème de système de fichiers sur le point de montage racine, vous voudriez pouvoir essayer de le réparer. Avec le montage en chevauchement, vous pouvez démonter le système de fichiers et utiliser fsckl’image fournie dans l’image de base pour le résoudre.

Cette fonctionnalité peut également être utile dans les systèmes nécessitant une sécurité renforcée pour pouvoir suivre le changement entre une ropartition et une rwautre.

Je me suis toujours demandé cela aussi.

Un simple emballage tel que:

#!/bin/sh
eval "mkdir -p \"\$$#\"" 
/bin/mount "$@"  

sauvegardé en tant que script exécutable nommé mountdans un répertoire remplaçant /bindans votre PATH devrait s'en occuper s'il vous dérange trop

(Avant d'exécuter le mountbinaire réel , il crée un répertoire nommé d'après le dernier argument de mount, si ce répertoire n'existe pas déjà.)

Alternativement, si vous ne voulez pas que les invocations échouées du mountwrapper créent des répertoires, vous pouvez faire:

#!/bin/sh
set -e
eval "lastArg=\"\$$#\""
test -d "$lastArg" || { mkdir "$lastArg"; madeDir=1; }
/bin/mount "$@"  ||  {  test -z "$madeDir" || rmdir "$lastArg"; }