% fichier / etc / mtab
/ etc / mtab: lien symbolique vers ../proc/self/mounts
% file / proc / mounts
/ proc / mounts: lien symbolique vers soi / mounts
%
/etc/mtabest un mécanisme de compatibilité. Il y a des décennies, Unix n'avait pas d'appel système pour lire les informations de montage existantes. Au lieu de cela, les programmes qui montaient des systèmes de fichiers étaient censés maintenir de manière coopérative et volontaire une table /etc/mtabde ce qui était monté où.
Pour des raisons évidentes, ce n'était pas un mécanisme idéal.
Linux a acquis la notion de "procfs", et une des choses qu'il a gagnées était une version maintenue par le noyau de cette table, sous la forme d'un mountsfichier pseudo-régulier. L '"appel système" pour lire les informations de montage hors du noyau est devenu une séquence d'ouverture-lecture-fermeture par rapport à ce fichier, suivie par l'analyse du résultat de la forme lisible par l'homme à la forme lisible par la machine (quelque chose qui a des captures subtiles, comme vous peut voir des rapports de bogues d'il y a un peu plus de quinze jours).
/etc/mtabainsi est devenu populairement un lien symbolique vers /proc/mounts, permettant aux programmes qui avaient câblé ce nom de continuer à lire une table de montage à partir de ce fichier, que les programmes qui montaient et démontaient les systèmes de fichiers n'avaient plus à faire explicitement quoi que ce soit eux-mêmes pour se tenir à jour. (Certains d'entre eux le seront toujours, cependant, s'il /etc/mtabs'avère être un fichier normal inscriptible. Et il y a quelques cas où les informations normalisées dans mountslesquelles il n'y a pas tout ce qui n'est pas du noyau n'est pas tout à fait ce qui est nécessaire; bien qu'elles ne l'emportent pas sur les problèmes généraux avec /etc/mtab.)
Chaque processus peut de nos jours avoir sa propre vue individuelle de ce qui est monté, et il y a donc maintenant des mountsfichiers individuels pour chaque processus dans le procfs, la propre table de chaque processus lui étant accessible via le selflien symbolique as self/mounts, et /proc/mountsest aussi maintenant une compatibilité mécanisme. (Fait intéressant, ni par processus mountsni le format de ne mountssont documentés dans le doco Linux actuel, bien que le mountinfofichier pseudo-régulier similaire le soit.)
SunOS / Solaris a un mécanisme similaire. Le /etc/mnttabfichier est en fait un système de fichiers à fichier unique, et en plus de lire le tableau, via un descripteur de fichier ouvert vers ce fichier, avec l' read()appel système, on peut surveiller les changements de point de montage avec poll()et obtenir diverses autres informations avec ioctl().
Dans HP-UX, /etc/mnttabest également le nom du fichier, mais à partir de la version 11, il s'agissait toujours d'un fichier normal dont le contenu était géré de manière coopérative par les programmes utilitaires système.
AIX n'exporte pas de table de texte lisible par l'homme que les programmes doivent analyser et il n'y a pas de fichier équivalent. De même, les BSD ont des appels système à part entière, getfsstat()sur FreeBSD et OpenBSD, pour que les programmes obtiennent la table de montage à partir du noyau sous une forme lisible par machine sans la rassembler via une forme intermédiaire lisible par l'homme.
Lectures complémentaires