Des cas d'utilisation de liens physiques? [fermé]


40

Dans quelles situations voudrait-on utiliser un lien dur plutôt qu'un lien symbolique? Personnellement, je n'ai jamais rencontré de situation dans laquelle je souhaiterais utiliser un lien fixe au lieu d'un lien symbolique, et le seul cas d'utilisation rencontré lors de la recherche sur le Web est la déduplication de fichiers identiques .


4
Vous trouverez ci-dessous de bonnes réponses, mais considérons le contexte historique (théorique). Quand Unix était nouveau, les lecteurs de disque étaient lents et avaient une capacité et une mise en mémoire tampon limitées. Un lien physique était simplement une autre entrée directe dans le système de fichiers dans le même fichier. Que vous accédiez à ls ou que vous aimiez l'appeler, liste , était sans importance. Si vous aviez créé un lien symbolique dans une liste , son utilisation impliquerait de le trouver dans le répertoire, de lire le fichier spécial appelé liste , de voir que vous voulez le fichier ls , de rechercher ls dans le répertoire et de lire le fichier ls réel à partir du disque. Une énorme différence de performance!
RichF

16
Eh bien, le premier lien dur vers un fichier est très utile.
Cessez de nuire à Monica le

@OrangeDog: Oui, mais vous n'avez besoin d'un champ de comptage de liens dans l'inode que si vous souhaitez prendre en charge plusieurs liens. (Vous aurez peut-être besoin d'un indicateur pour la version en mémoire d'inodes afin de traiter le cas non lié mais toujours ouvert. Fsck après une panne sans journalisation devrait toujours rechercher des inodes sans liens de toute façon.)
Peter Cordes

1
La sémantique des répertoires POSIX devrait être conçue différemment: ..est toujours le même inode que .dans le répertoire parent. Vous findpouvez par exemple vérifier que link-count = 2 pour détecter les répertoires feuilles et éviter stataux entrées de readdir de rechercher des sous-répertoires. Mais ce n'est qu'une fonctionnalité mineure activée par la prise en charge des liens physiques de fichiers autres que de répertoires (fichiers ordinaires, liens symboliques, périphériques, sockets et tubes nommés). (Oui, les liens symboliques ont leur propre inode et peuvent être liés de manière permanente.)
Peter Cordes

1
Une des raisons d'utiliser des liens durs que je n'ai pas vu dans mon analyse de SO, est de nature "globale". Imaginez un système de fichiers où les fichiers sont généralement petits (généralement des mémos courts, par exemple), mais pour garder les choses organisées, vous pouvez avoir besoin de pointeurs sur le même fichier à différents endroits. Avec les liens symboliques, chaque pointeur utilise un inode. De tels systèmes de fichiers peuvent déjà avoir un problème avec le manque d'inodes. L'utilisation de liens physiques en tant qu'indicateurs aide à résoudre ce problème. les inodes sont en nombre limité; leurs noms ne sont pas (du moins, pas de la même manière).
mathguy

Réponses:


27

Outre l'utilisation de la sauvegarde mentionnée dans un autre commentaire, qui inclut, je crois, les instantanés sur un volume BTRFS, un scénario d'utilisation pour les liens physiques via des liens logiciels est une collection de fichiers triés par balises. (Ce n'est pas forcément la meilleure méthode pour créer une collection, une méthode basée sur une base de données est potentiellement meilleure, mais pour une collection simple qui est raisonnablement stable, ce n'est pas si mal.)

Une collection de médias dans laquelle tous les fichiers sont stockés dans un, un plat, un répertoire et sont classés dans d'autres répertoires en fonction de divers critères, tels que: année, sujet, artiste, genre, etc. Il peut s'agir d'une collection de films personnelle ou du collectif d'un studio commercial travaux. Essentiellement terminé, le fichier est enregistré, peu susceptible d’être modifié, et trié, éventuellement en plusieurs emplacements par liens.

N'oubliez pas que les concepts "original" et "copie" ne s'appliquent pas aux liens physiques: chaque lien vers le fichier est un original, il n'y a pas de "copie" au sens habituel. Pour la description du cas d'utilisation, toutefois, les termes imitent la logique du comportement.

"L'original" est enregistré dans le répertoire "catalogue" et les "copies" triées sont liées à ces fichiers. Les attributs de fichier sur les répertoires de tri peuvent être définis sur r / o, ce qui empêche toute modification accidentelle des noms de fichiers et de la structure triée, tandis que les attributs du répertoire de catalogue peuvent être r / w, ce qui permet de le modifier selon les besoins. (Par exemple, certains lecteurs essaient de renommer et de réorganiser des fichiers en fonction de balises incorporées dans le fichier multimédia, à partir de la saisie de l'utilisateur ou de la recherche sur Internet.) De plus, les attributs des répertoires "copy" pouvant être différents de le répertoire "original", la structure triée pourrait être mise à la disposition du groupe, ou du monde, avec un accès restreint, tandis que le "catalogue" principal est uniquement accessible à l'utilisateur principal, avec un accès complet. Les fichiers eux-mêmes, cependant, auront toujours les mêmes attributs sur tous les liens vers cet inode. (Les ACL pourraient être explorées pour améliorer cela, mais pas mon domaine de connaissances.)

Si l'original est renommé ou déplacé (le répertoire "catalogue" devient trop volumineux pour être géré, par exemple), les liens fixes restent valides, les liens symboliques étant rompus. Si les "copies" sont déplacées et que les liens symboliques sont relatifs, les liens symboliques seront, à nouveau, rompus et les liens physiques ne le seront pas.

Remarque: il semble exister une incohérence dans la façon dont différents outils signalent l'utilisation du disque lorsque des liens symboliques sont impliqués. Avec les liens durs, cependant, cela semble cohérent. Donc, avec 100 fichiers dans un catalogue triés dans une collection de "tags", il pourrait facilement y avoir 500 "copies" liées. (Pour une collection de photographies, par exemple la date, le photographe et une moyenne de 3 balises "subject".) Dolphin, par exemple, indiquerait cela comme 100 fichiers pour les liens fixes et 600 fichiers si des liens symboliques sont utilisés. Fait intéressant, il indique la même utilisation de l’espace disque, de sorte qu’il ressemble à une vaste collection de petits fichiers pour les liens symboliques et à une petite collection de gros fichiers pour les liens physiques.

Un inconvénient à ce type de cas d'utilisation est que, dans les systèmes de fichiers qui utilisent COW, la modification de "l'original" peut rompre les liens fixes, mais pas les liens souples. Mais si l'intention est de conserver la copie originale, après l'avoir modifiée, sauvegardée et triée, COW n'entre pas dans le scénario.


3
FYI: Les instantanés btrfs ne sont pas des liens fixes. Ils ont un comportement différent (par exemple, modifier une copie ne modifie pas l'autre). Et statne montrera qu'un seul lien.
derobert

@derobert Pas sûr du fonctionnement des instantanés, une petite enquête montre des choses intéressantes. Les fichiers / répertoires non statmodifiés affichent le même numéro d'inode, mais un identifiant d'appareil différent. Doit avoir quelque chose à voir avec la façon dont les sous-volumes sont superposés sur le volume principal, rarement monté. Je suspecte que si le volume principal était monté, statle nombre de liens serait égal au nombre d'instantanés contenant cette version du fichier. COW prend probablement soin de modifier celui qui n’affecte pas les autres. De simples spéculations basées sur une curiosité légère, mais pas assez curieuses pour creuser plus profondément.
Gypsy Spellweaver

Chaque lien symbolique a son propre inode, il utilise donc une entrée d'inode dans le système de fichiers. Les systèmes de fichiers Unix traditionnels exigent que vous choisissiez l’espace à réserver pour les inodes au moment de la création du système de stockage, au lieu de l’allouer à la demande, comme le fait XFS. Il est donc important de noter que la version du lien symbolique utiliserait beaucoup plus d'inodes (même en plus des implications de l'empreinte du cache VFS).
Peter Cordes

23

Les liens physiques sont utiles dans les cas où vous ne souhaitez pas lier l'existence des deux fichiers. Considère ceci:

touch a
ln -s a b
rm a

Maintenant best inutile. (Et ces étapes peuvent se dérouler assez loin l'une de l'autre, être effectuées par différentes personnes, etc.)

Alors qu'avec un lien dur,

touch a
ln a b
rm a

b est toujours présent et correct.


8
@MatthewCline Ce comportement serait souhaitable lors de la gestion de sauvegardes incrémentielles efficaces. En particulier lorsque des anciennes sauvegardes sont supprimées, dans un système de sauvegarde à liaison souple, vous devez vérifier et relier tous les nouveaux fichiers / liens de sauvegarde à une base valide, alors que les liens durs effectuent ce travail "gratuitement" au niveau inode. timeshift / backintime, par exemple, utilise beaucoup les liens durs.
orzechow

3
@orzechow Je ne pense pas que vous souhaitiez un comportement de liaison physique à proximité de votre système de sauvegarde. github.com/bit-team/backintime/wiki/… backintime suppose stupidement que toutes les modifications apportées aux fichiers se feront par un cycle suppression / création plutôt que par une mise à jour en place.
DepressedDaniel

10
Les liens physiques @DepressedDaniel sont bien dans un système de sauvegarde, vous ne voulez simplement pas que les sauvegardes soient liées aux fichiers en direct. Mais dans tous les cas, une sauvegarde ne devrait jamais être accessible directement à partir d'un système en direct ...
Stephen Kitt

1
Ce n'est pas une réponse - spécifiquement, ce n'est pas un cas d'utilisation. C'est juste une démonstration du comportement des liens durs.
user394

1
@ ThomasPadron-McCarthy, c'est un malentendu. BiT utilise des liens physiques uniquement pour lier des fichiers identiques dans des instantanés différents. Ils ne sont PAS liés au fichier d'origine! (Je suis le BiT Dev)
Germar le

11

Un programme unique peut changer de comportement en fonction du nom sous lequel il est lancé:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

Qui dans la source est décidé via quelque chose comme

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

bien que les détails exacts varient en fonction du système d'exploitation et de la langue utilisée.

Cela permet (la plupart du temps) de ne pas avoir à compiler du code identique en deux binaires (la plupart du temps) identiques. Gardez à l'esprit les dates unix à l'époque où l'espace disque était extrêmement coûteux, même si selon Stevens du chapitre 4 de l'APUE, des liens symboliques ont été mis en place dans BSD4.2 (1983) pour remplacer diverses limitations des liens durs. Un programme de test pour vérifier si le nom du lien symbolique est utilisé, car le nom du programme pourrait ressembler à ceci:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

Et testé via:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

4
Mais n'est-ce pas habituellement traité avec des liens symboliques?
Matthew Cline

1
Cela pourrait être le cas aujourd'hui, mais les liens symboliques n'existaient pas avant 4.2BSD (1983), selon Stevens dans APUE.
Thrig

4
@thrig, la question demande spécifiquement des cas d'utilisation qui ne peuvent pas être réalisés par des liens symboliques ou qui sont, au moins, préférables plutôt que d'utiliser des liens symboliques. Votre réponse s’applique aux HL et aux SL.
Marcelo

3
BusyBox prend cela au maximum.
Max Ried

8

Lorsque mon logiciel P2P a fini de télécharger un certain fichier, celui-ci est placé dans un répertoire spécifique. Les fichiers téléchargés n’ont pratiquement jamais besoin d’être édités. Le cas le plus courant est que je crée un lien physique dans un répertoire différent où j'ai besoin du fichier.

Avantages:

  • Je partage toujours le fichier dans le réseau P2P comme je le devrais, même si je rmoumv la "copie".
  • Le fichier est également sur le chemin où j'en ai besoin; la plupart de ces endroits ne sont pas partagés.
  • je peux rm le "original" pour arrêter de partager le fichier; cette opération n'affecte pas la "copie" à l'endroit désiré.
  • Mon espace disque est utilisé une seule fois.

Le point principal: si je savais d'avance quel fichier je voudrais d' rmabord, je pourrais utiliser un lien symbolique. Mais je ne sais jamais.


6

Les systèmes de fichiers constituent un moyen simple, mais efficace, d’organiser et de classer les fichiers (c’est leur raison d’être primordiale). Les liens durs permettent une plus grande flexibilité dans ce domaine.

Comme mentionné, il n'y a pas de concept d'original et de copies lorsqu'il s'agit de liens durs, toutes les entrées de répertoire (liens durs) sont simplement des références à l'existence du fichier (point sur son inode) sans précédent, il n'y a donc pas non plus de lien dur rompu. .

Donc là , il y a quelques - uns des cas d'utilisation qui les liens physiques fréquentent , mais les liens logiciels ne le font pas :

  1. Imaginez que vous ayez une collection de films, de musique ou d’autres supports et que vous souhaitiez appliquer différents critères de classification, comme des chansons classées par artiste dans une branche (chaque artiste a son propre sous-répertoire); par genre dans une autre branche (chacun dans un sous-répertoire différent), etc. Cependant, vous ne voulez pas dupliquer les fichiers, ni décider où placer l'original, pour avoir la liberté de reclassifier sans avoir à le faire. gérer "et relier les fichiers lors du déplacement afin d'éviter les liens brisés.

  2. Une autre raison est d’éviter le gaspillage d’espace de stockage qui serait nécessaire pour avoir plusieurs copies du même fichier tout en permettant au chrootsystème de bénéficier d’un sous-ensemble de fichiers dans la racine du système de fichiers "maître" (les liens symboliques ne pourraient jamais référencer des fichiers de l’extérieur). le chrootbac à sable, même s’ils ont des chemins relatifs).

  3. Les ..sous - répertoires sont une autre raison très importante mais rarement mentionnée . Les ..répertoires sont en fait (dans la plupart des implémentations unix) des liens durs vers le répertoire parent. Sans liens durs, cela doit être implémenté d’une manière complètement différente, alors que l’existence de liens durs le rend très facile à implémenter.


1
Pour le point 1, utiliser des uuids comme nom "canonique" pour les fichiers et créer tous les liens symboliques des noms lisibles par l'homme vers les uuids est une solution alternative.
R ..

Bien que la suggestion d'utiliser des uuids semble correcte d'un point de vue académique, utiliser uuids pour les noms de fichiers ne semble pas très pratique, et là encore, l'objectif est de simplifier les choses, pas de les rendre plus difficiles ou "moins compréhensibles par l'homme". De plus, avoir uudis pour la référence de fichier "canonique" serait simplement une indirection supplémentaire vers l'inode de fichier réel, il n'y a donc aucun intérêt à utiliser cette approche car elle n'offre aucun avantage, mais présente des inconvénients tels que: impact sur les performances, performances supplémentaires. espace disque pour stocker plus d'entrées de répertoire, avoir un tas de fichiers avec des noms "bizarres" tout autour ...
Marcelo

5

Très commun, exemple du monde réel qui nécessite des liens durs:

git clone --reference <repository>

Cela clone à partir d'un dépôt Git local avec une copie presque nulle. Au lieu de copier les fichiers objets (fichiers immuables utilisés par Git pour sa "base de données"), il les lie simplement.

Tout repo peut supprimer un objet, mais l'inode reste valable pour le reste du repo. Et si un objet est supprimé de tous les dépôts, il est supprimé du disque. Les liens durs constituent une solution extrêmement robuste et rapide. Très commun dans les serveurs CI.


Il existe une version non-hard-link: git clone --shared <repository>. Cependant, ceci est instable et comporte de nombreuses autres mises en garde puisque tout le monde travaille sur le même répertoire.


4

J'ai récemment eu un cas d'utilisation pour une procédure de mise à jour assez sûre pour les systèmes U-Boot où uImageun lien symbolique pointant vers l'image à démarrer, l'idée était qu'une panne de courant ne devrait poser aucun problème, peu importe à quel moment de la mise à jour. le processus se produit (en supposant que le système de fichiers fonctionne bien):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Sans liens durs, cela ne serait pas si simple.

/modifier:

Grâce aux commentaires, je sais maintenant qu'il serait préférable de faire:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

(Le rmest ici pour pouvoir mieux sortir d'un état étrange, par exemple s'il uImages'agit d'un imprévu qui ferait mvéchouer [mais pas nécessairement la ln -sfsolution précédente ].)


2
+1 parce que, sur le plan conceptuel, c'est une très bonne raison, mais malheureusement, ce ln -sfn'est pas atomique. Il supprime l'ancien lien symbolique et en crée un nouveau. Pour corriger cela , vous devez créer un nouveau lien symbolique avec un nom temporaire et rename(2)( mv) pour nom de celui que vous souhaitez remplacer.
R ..

@R .. Tu as raison! 😲 stat("uImage", {st_mode=S_IFREG|0777, st_size=0, ...}) unlink("uImage"),symlink("backup_image.bin", "uImage")
phk

1
BTW, voir ici pour ma version de install.shcela résout le problème: git.musl-libc.org/cgit/musl/tree/tools/install.sh
R ..

@R .. Notez que mvmême avec -fpeut échouer si la destination existe déjà, par exemple un lien symbolique faisant partie d'une boucle de liens symboliques. Démo:ln -sf foo bar; ln -sf bar foo; echo "Before:"; ls -l foo bar; >testfile; mv testfile foo || { echo "Using mv -f"; mv -f testfile foo; }; echo "After:"; ls -l foo bar
phk

3

Une utilisation que j'ai eu pour les liens durs est lors du téléchargement ou de la décompression d'un fichier endommagé. Le programme qui télécharge ou décompresse (par exemple, unzip ou unrar) supprime souvent automatiquement le fichier incomplet lorsqu'il rencontre une erreur, et il n’ya généralement pas d’option pour le conserver. Si je veux conserver le fichier, je peux établir un lien solide avec celui-ci.


3

BackupPC est un système de sauvegarde qui utilise des liens physiques sur les serveurs pour fournir une déduplication au niveau des fichiers.

Les fichiers sont d'abord stockés dans une arborescence de répertoires "pool" en fonction de leur hachage md5. Toute sauvegarde utilisant ce fichier crée un lien matériel avec le fichier de pool. Lorsque les sauvegardes expirent / sont supprimées, leurs liens physiques sont supprimés du système de fichiers.

Les liens physiques sont supérieurs aux liens symboliques ici car ils fournissent un comptage automatique des références. Un travail cron supprime périodiquement les fichiers du répertoire du pool ne comportant pas plus d'un lien.

Cette méthode présente certains inconvénients (principalement le fait qu’il est difficile d’utiliser des outils basés sur un système de fichiers pour répliquer le magasin de sauvegarde), mais elle s’est avérée assez robuste en pratique.


Autre cas d’utilisation: le serveur d’applications Web tomcat java traite les noms de fichiers comme des métadonnées. Un fichier java "war" doit être nommé en fonction de son chemin d'accès sur le serveur Web.

par exemple: foo.war est le code Java qui sert l'URL/foo

Malheureusement, il résout les liens symboliques avant de prendre cette décision.

Supposons donc que vous souhaitiez déployer une version d’application et lui attribuer un nom de fichier descriptif (avec, par exemple, un numéro de version ou une date). Vous ne pouvez pas créer de lien symbolique vers le fichier avec le nom "réel" - vous devez créer un lien dur.

foo.warlien symbolique vers foo-20170129.warne fonctionne pas

foo.warrelié durement aux foo-20170129.warœuvres.

Je n'aime pas ce comportement de tomcat, mais les liens physiques me permettent de le contourner.

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.