Pourquoi les liens matériels ne sont-ils valables que dans le même système de fichiers?

22

Je lis cette introduction à la ligne de commande de Mark Bates.

Dans le premier chapitre, il mentionne que les liens durs ne peuvent pas s'étendre sur les systèmes de fichiers.

Une chose importante à noter sur les liens durs est qu'ils ne fonctionnent que sur le système de fichiers actuel. Vous ne pouvez pas créer de lien dur vers un fichier sur un autre système de fichiers. Pour ce faire, vous devez utiliser des liens symboliques, section 1.4.3.

Je ne connais qu'un seul système de fichiers. Celui commençant par root ( /). Cette déclaration selon laquelle les liens durs ne peuvent pas s'étendre sur les systèmes de fichiers n'a aucun sens pour moi.

L' article Wikipedia sur les systèmes de fichiers Unix n'est pas non plus utile.

filesystems hard-link

— Anton Paras
source

29

J'espère pouvoir répondre à cette question d'une manière qui vous semble logique. Un système de fichiers sous Linux est généralement composé d'une partition formatée de différentes manières (je dois aimer le choix!) Sur laquelle vous stockez vos fichiers. Que ce soit vos fichiers système, ou vos fichiers personnels ... ils sont tous stockés sur un système de fichiers. Vous semblez comprendre cette partie.

Mais que se passe-t-il si vous partitionnez votre disque dur pour avoir plus d'une partition (pensez à Apple Pie coupé en morceaux), ou ajoutez un disque dur supplémentaire (peut-être une clé USB?). Pour des raisons d'argument, ils ont tous également des systèmes de fichiers.

Lorsque vous regardez les fichiers sur votre ordinateur, vous voyez une représentation visuelle des données sur le système de fichiers de votre partition. Chaque nom de fichier correspond à ce qu'on appelle un inode, c'est-à-dire où vivent réellement vos données, en coulisses. Un lien dur vous permet d'avoir plusieurs "noms de fichiers" (faute d'une meilleure description) qui pointent vers le même inode. Cela ne fonctionne que si ces liens durs se trouvent sur le même système de fichiers. Un lien symbolique pointe à la place sur le "nom de fichier", qui est ensuite lié à l'inode contenant vos données. Pardonnez mes illustrations grossières mais j'espère que cela explique mieux.

image.jpg             image2.jpg
          \           /
           [your data]

ici, image.jpg et image2.jpg pointent directement vers vos données. Ce sont deux liens durs. Toutefois...

image.jpg    <-----------  image2.jpg
           \ 
             [your data]

Dans cet exemple (grossier), image2.jpg ne pointe pas vers vos données, il pointe vers l'image.jpg ... qui est un lien vers vos données.

Les liens symboliques peuvent fonctionner au-delà des limites du système de fichiers (en supposant que le système de fichiers est attaché et monté, comme votre clé USB). Cependant, un lien dur ne peut pas. Il ne sait rien de ce qui se trouve sur votre autre système de fichiers, ni de l'emplacement de stockage de vos données.

Espérons que cela aide à mieux comprendre.

— dubkat
source

Merci. Je n'ai pas réalisé que différentes partitions de fichiers sont appelées "systèmes de fichiers".

— Anton Paras

1

l'une des choses que vous pouvez faire avec une partition est d'y mettre un système de fichiers, il y a d'autres endroits où vous pouvez mettre des systèmes de fichiers et d'autres choses que vous pouvez faire avec des partitions, mais l'option la plus courante est celle-ci.

— Jasen

10

Il y a une hiérarchie de fichiers qui commence par "/". Il aura un ou plusieurs systèmes de fichiers montés

— mpez0

@ mpez0: Même pas, avec chroot(2)ou par exemple une conteneurisation réelle, vous pouvez avoir plusieurs hiérarchies, qui peuvent n'avoir rien à voir les unes avec les autres.

— Kevin

@Kevin, chrootisole une partie de la hiérarchie pour un processus et ses descendants, mais le parent a toujours une hiérarchie complète. La conteneurisation peut le faire, selon sa proximité avec une machine virtuelle. Mais combien de détails peut-on intégrer dans un commentaire? Merci,

— mpez0

23

Le système de fichiers est composé d'une structure de répertoires composée d'entrées de répertoires pour organiser les fichiers. Chaque entrée de répertoire associe un nom de fichier à un inode .

Les liens logiciels ( symboliques ) sont des entrées de répertoire qui ne contiennent pas de données, elles pointent simplement vers une autre entrée (un fichier ou un répertoire dans le même système de fichiers ou un autre système de fichiers). Et lorsque vous supprimez le fichier pointé, le lien symbolique devient inutilisable.

Les liens matériels sont une entrée de répertoire qui contient le nom de fichier et le numéro d' inode . Lorsque vous supprimez le dernier lien dur, vous ne pouvez plus accéder au fichier.

Conclusion:

Comme l' inode est une structure de données utilisée pour représenter un objet du système de fichiers, il est interne au système de fichiers et vous ne pouvez pas pointer vers un inode d'un autre système de fichiers.

Ainsi, les liens physiques ne sont valables que dans le même système de fichiers, mais les liens logiciels (lien symbolique) peuvent s'étendre sur les systèmes de fichiers car ils pointent simplement vers une autre entrée de répertoire (l'interface du système de fichiers et non un objet interne).

— Facundo Victor
source

1

Belle réponse concise.

— dubkat

Que se passera-t-il si un autre système de fichiers (disons USB) aura un fichier avec le même NOM, auquel notre lien symbolique est connecté sur notre système de fichiers?

— Josef Klimuk

@JosefKlimuk, un lien logiciel pointerait vers un chemin, disons /mnt/myfile. Si vous montez un autre système de fichiers dans /mnt/. Le lien logiciel serait résolu vers une entrée du système de fichiers monté sous /mnt/. Ainsi, si vous montiez le système de fichiers à partir de votre périphérique USB /mnt, le lien logiciel se résoudrait en une entrée sur ce système de fichiers.

— Facundo Victor

2

Le système de fichiers racine peut être composé de plusieurs systèmes de fichiers; /usr/localpeut être monté sur une partition distincte et /homepeut être sur une autre partition sur un disque en réseau ailleurs. Dans ce cas, un lien dur pour /usr/local/bin/git(par exemple) ne peut pas être créé en dehors de /usr/local, car il couvrirait les systèmes de fichiers .

La raison en est que les inodes sont alloués séparément pour /, /usr/localet /home(encore une fois, dans cet exemple), et lorsque vous créez un lien dur, vous créez vraiment un nom supplémentaire pour un inode.

— Kusalananda
source

2

Les liens durs ont pour effet de maintenir leur cible en vie. Tant que n'importe quel lien dur est accessible, le système s'assurera que sa cible ne peut pas être libérée. Il est donc nécessaire que tous les supports qui pourraient contenir des liens durs vers un inode particulier soient montés chaque fois que le système essaiera de déterminer s'il existe des références à celui-ci.

Étant donné que la durée de vie des inodes est généralement déterminée en conservant le nombre de références plutôt qu'en analysant les références, il pourrait être possible d'organiser des choses pour que deux systèmes de fichiers ou plus qui détiennent des liens entre eux puissent être utilisés indépendamment, à condition qu'il n'y ait pas besoin d'utiliser des liens qui fait le pont entre les systèmes, et à condition qu'il ne soit pas nécessaire d'utiliser fsck sur l'un ou l'autre. Si l'inode compte sur l'un des systèmes, cependant, la seule façon de rendre ce système utile à nouveau serait d'utiliser une forme d'opération fsck qui pourrait analyser les deux systèmes de fichiers pour les références. En raison de cette contrainte, bien qu'il soit possible d'autoriser deux systèmes de fichiers interconnectés à être utilisés indépendamment, les avantages de le faire seraient probablement trop limités pour que cela en vaille la peine.

— supercat
source

Bon point, mais un peu trop tangentiel pour être une bonne réponse.

— Joe

@Joe: Autoriser des liens durs vers des systèmes de fichiers croisés imposerait un certain nombre de difficultés techniques, mais la plupart d'entre elles pourraient être surmontées, ce qui soulève la question de savoir s'il existe une raison impérieuse pour laquelle elles ne devraient pas l' être. Le problème de persistance peut sembler obscur, mais contrairement aux autres problèmes, il ne peut être résolu qu'en imposant de sévères restrictions sémantiques sur l'utilisation de ces liens, ce qui limiterait considérablement leur valeur.

— supercat

Bon point. Un système de fichiers peut être monté sur un autre appareil et modifié, de sorte que l'inode et les liens peuvent être «désynchronisés». Chaque système de fichiers pourrait avoir un GUID et le lien pourrait incorporer ce GUID pour suivre l'inode à travers les systèmes de fichiers. Il pourrait également y avoir une sorte de journal sur le FS, puis lorsqu'il est monté, le système hôte n'aurait pas besoin de le scanner, mais pourrait simplement lire le journal et "rattraper" les modifications de liaison de l'inode (quand le supprimons-nous, bien que?). En bout de ligne, le FS sous-jacent devrait être modifié de manière non triviale et ne fonctionnerait que sur des systèmes de fichiers compatibles.

— Rolf

1

Un numéro d' inode unique utilisé pour représenter le fichier dans chaque système de fichiers. Tous les liens durs basés sur le numéro d'inode. Lien de référence du système de fichiers ici .

— msc
source