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.
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.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,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).
la source
/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.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.la source
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.
la source
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 .
la source