Comment findmnt est-il capable de répertorier les montages de liaison?


11

Beaucoup de gens continuent de dire que Linux ne conserve pas d'informations sur les montages de liaison, il n'y a donc aucun moyen d'obtenir une liste d'entre eux et leurs sources. Voici quelques exemples:

  • à partir d' un des commentaires ici :

    IIRC cette information n'est conservée nulle part: après mount --bind, les deux exemplaires sont équivalents, il n'y en a pas un qui soit plus «original» que l'autre. Après tout, il ne pourrait y avoir d'original si vous l'aviez déjà démonté /mnt.

  • d' une réponse sur ce site :

    Donc, la seule façon de se souvenir des montures étaient des montures de liaison est le journal des commandes de montage restantes /etc/mtab. Une opération de montage de liaison est indiquée par l'option de montage de liaison (qui entraîne l'ignorance du type de système de fichiers). Mais mount n'a pas d'option pour répertorier uniquement les systèmes de fichiers montés avec un ensemble particulier d'ensembles d'options.

  • à partir d' un rapport de bogue Debian :

    C'est intentionnel. Les deux points de montage sont entièrement égaux à tous égards, de sorte que le noyau ne conserve aucun indicateur pour les différencier.

Ce qui précède est cependant insensé. L'outil findmntest capable de répertorier les chemins source des montages de liaison (sous la forme de device[source-path]; j'essaie également de le faire lister uniquement le chemin source et non le périphérique). Si le noyau Linux doit maintenir un montage de liaison, alors ces informations doivent être stockées quelque part , sinon il ne pourrait pas savoir à quoi il /homeest lié /users. Alors, où sont ces données? Est-il stocké dans une région obscure de la RAM? Est -ce que findmntregarder dans /procquelque part?


Quelle version findmntutilisez-vous et quelles options proposez-vous? Le mien ne l'imprime pas comme ça et regarde le code source qu'il semble utiliser _PATH_PROC_MOUNTINFOet /proc/self/mountinfoqui ne contient pas non plus ces informations.
Bratchley

OK, je suppose que la /proc/self/mountinforestructuration a été relativement récente. J'étais sur ma machine RHEL6 avant qui n'avait pas les informations de chemin mais ma machine RHEL7 en a et comme mentionné dans votre lien Wheezy aussi.
Bratchley

Ce n'est pas un non-sens: c'était vrai avec les noyaux plus anciens, mais les noyaux plus récents suivent les informations.
Gilles 'SO- arrête d'être méchant'

@Gilles Alors, comment un montage de liaison pourrait-il persister si les informations selon lesquelles un répertoire est monté sur un autre ne sont pas suivies?
Melab

@Melab En fait, il est plus facile pour une monture de liaison de persister si vous ne suivez pas qu'il s'agit d'une monture de liaison. Quand /dev/Aest monté à /Bet vous le faites mount --bind /B /C, les noyaux plus anciens ne se souviennent que de, /B → /dev/Aet /C → /dev/Ails ne se souviennent d'aucune relation entre /Bet /C. Le démontage /Bn'a donc naturellement aucun effet /C. Les noyaux plus récents se souviennent que /Cc'était un montage de liaison /B, mais d'une manière qui n'empêche pas /Cde continuer à fonctionner s'il /Bn'est pas monté, je ne sais pas exactement comment.
Gilles 'SO- arrête d'être méchant'

Réponses:


12

Vous avez un peu mal compris; les deux points de montage sont égaux en termes d'autorisations, d'indicateurs, etc. car la liaison redirige efficacement l'accès d'un chemin à un autre. Mais ils sont encore distincts .

Si vous regardez, /proc/self/mountinfovous verrez la vue du noyau du monde de montage pour ce processus (les espaces de noms rendent les choses plus compliquées; il n'y a pas qu'une seule vue de la table de montage).

man 5 procexpliquera le format de ce fichier, mais vous pouvez voir la hiérarchie de l'arborescence et où les montures de liaison ont leur "parent". Il s'agit du fichier qui findmntanalyse.


9

Linux ne conserve pas les informations sur le montage qui était un montage de liaison . Il conserve des informations sur tous les montages, y compris les montages de liaison .

C'est assez similaire aux liens durs. Monte les liens vers les systèmes de fichiers comme les noms de fichiers vers les inodes. Les seules différences sont que les montages ont également des indicateurs par point de montage et peuvent faire référence à un sous-répertoire du système de fichiers cible au lieu de la racine du système de fichiers.

Lorsque vous créez un lien dur, le système de fichiers n'enregistre pas quel nom de fichier était l'original et quel était le lien dur. Les deux se réfèrent simplement au même inode. Si vous dissociez le fichier d'origine, il est impossible de distinguer la situation de la création directe du fichier avec le deuxième nom de fichier.

Retour pour lier les montages: Le noyau conserve une table qui contient le système de fichiers (identifié par une paire de nombres majeurs: mineurs), le point de montage, le chemin relatif à la racine du système de fichiers et quelques indicateurs. Vous pouvez accéder à cette liste en consultant /proc/self/mountinfo. (Cela devient plus compliqué lorsque les espaces de noms sont impliqués, comme l'a mentionné @ stephen-harris). findmntanalyse cette liste.

Si votre racine est /dev/sda1avec le majeur: mineur 8:1et que vous exécutez mount --bind /a /b /proc/self/mountinfocontiendra des lignes similaires à ceci:

1 0 8:1 / / rw - ext4 /dev/sda1 rw,errors=remount-ro
2 1 8:1 /a /b rw - ext4 /dev/sda1 rw,errors=remount-ro

Si votre /homeest /dev/sda2avec le majeur: mineur 8:2et que vous exécutez , mount --bind /home /usersil ressemblera à ceci:

1 0 8:1 / / rw - ext4 /dev/sda1 rw,errors=remount-ro
2 1 8:2 / /home rw - ext4 /dev/sda2 rw
3 1 8:2 / /users rw - ext4 /dev/sda2 rw

Les colonnes pertinentes pour votre question sont les troisième, quatrième et cinquième. Il s'agit de l'ID du système de fichiers (pour les systèmes de fichiers réels, c'est la même chose que le périphérique majeur: mineur; pour les systèmes de fichiers virtuels comme tmpfs, c'est [0: compteur ]), le chemin relatif à la racine du système de fichiers qui est liée au point de montage (généralement / pour la normale montures, peut être n'importe quoi pour les montures de liaison) et le point de montage.
Pour la signification des colonnes restantes, voir la documentation du noyau Linux .

findmntappelle le chemin source par rapport à la racine du système de fichiers "FSROOT". Vous pouvez utiliser findmnt -o TARGET,FSROOTpour l'obtenir. Si vous voulez le chemin source absolu, vous devrez probablement analyser /proc/self/mountinfopar vous-même et combiner les informations sur les montages pour le même système de fichiers.

Pour plus d'informations, voir ma réponse à "Liste uniquement des montures de liaison" .


Si /proc/self/mountinfopeut contenir des lignes comme 2 1 8:1 /a /b rw - ext4 /dev/sda1 rw,errors=remount-ro, alors Linux certainement ne conserver certaines informations sur les montages se lient.
Melab

Regardez mon deuxième exemple. Il conserve les informations sur le système de fichiers qui a été monté et sur le chemin relatif à la racine du système de fichiers qui a été monté . Donc , pour mount --bind /home/melab /mntla ligne résultante pourrait ressembler à une des opérations suivantes selon le de /homeet /home/melabest un point de montage: 3 1 8:1 /home/melab /mnt rw - ext4 /dev/sda1 rw, 3 1 8:2 /melab /mnt rw - ext4 /dev/sda2 rw,3 1 8:3 / /mnt rw - ext4 /dev/sda3 rw
cg909

Il est vrai que quelque chose de différent de celui /de la quatrième colonne indique souvent un montage de liaison. Mais il pourrait également s'agir d'un sous-volume Btrfs.
cg909

Est /dev/sda3censé être monté à /home/melab?
Melab

Oui. Dans mon exemple, j'ai utilisé /dev/sda1as /, /dev/sda2as /homeand /dev/sda3as/home/melab
cg909
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.