web-dev-qa-db-fra.com

Cas d'utilisation de liens durs?

Dans quelles situations souhaiterait-on utiliser un lien physique plutôt qu'un lien logiciel? Personnellement, je n'ai jamais rencontré de situation où je souhaiterais utiliser un lien physique sur un lien logiciel, et le seul cas d'utilisation que j'ai rencontré lors d'une recherche sur le Web est déduplication de fichiers identiques =.

filesystemshard-link
40
Matthew Cline

Mis à part l'utilisation de la sauvegarde mentionnée dans un autre commentaire, qui, je crois, inclut également les instantanés sur un volume BTRFS, un cas d'utilisation pour les liens physiques sur les liens logiciels est une collection de fichiers triés par balises. (Pas nécessairement 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 trop mal.)

Une collection multimédia où tous les fichiers sont stockés dans un seul répertoire, à plat, et triés dans d'autres répertoires en fonction de divers critères, à savoir: année, sujet, artiste, genre, etc. Il peut s'agir d'une collection de films personnels ou d'un collectif de studios commerciaux. travaux. Essentiellement terminé, le fichier est enregistré, peu susceptible d'être modifié et trié, éventuellement en plusieurs emplacements par des liens.

Gardez à l'esprit que le concept d '"original" et de "copie" ne s'applique pas aux liens physiques: chaque lien vers le fichier est un original, il n'y a pas de "copie" au sens normal. Pour la description du cas d'utilisation, cependant, les termes imitent la logique du comportement.

L '"original" est enregistré dans le répertoire "catalogue" et les "copies" triées sont liées en dur à ces fichiers. Les attributs de fichier sur les répertoires de tri peuvent être définis sur r/o, empêchant toute modification accidentelle des noms de fichier et de la structure triée, tandis que les attributs sur le répertoire de catalogue peuvent être r/w, ce qui permet de le modifier selon les besoins. (Par exemple, les fichiers musicaux dans lesquels certains joueurs tentent de renommer et de réorganiser les fichiers en fonction des balises incorporées dans le fichier multimédia, à partir de l'entrée utilisateur ou de la récupération Internet.) le répertoire "original", la structure triée pourrait être mise à la disposition du groupe, ou du monde, avec un accès restreint alors que le "catalogue" principal n'est accessible qu'à l'utilisateur principal, avec un accès complet. Cependant, les fichiers eux-mêmes auront toujours les mêmes attributs sur tous les liens vers cet inode. (ACL pourrait être exploré 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 à gérer, par exemple), les liens physiques restent valides, les liens logiciels sont rompus. Si les "copies" sont déplacées et que les liens logiciels sont relatifs, alors les liens logiciels seront, encore une fois, rompus et les liens matériels ne le seront pas.

Remarque: il semble y avoir une incohérence sur la façon dont les différents outils signalent l'utilisation du disque lorsque des liens logiciels sont impliqués. Avec les liens physiques, cependant, cela semble cohérent. Ainsi, avec 100 fichiers dans un catalogue triés en une collection de "balises", il pourrait facilement y avoir 500 "copies" liées. (Pour une collection de photographies, disons la date, le photographe et une moyenne de 3 balises "sujet".) Dolphin, par exemple, indiquerait que 100 fichiers pour les liens physiques et 600 fichiers si des liens logiciels sont utilisés. Fait intéressant, il signale la même utilisation de l'espace disque dans les deux sens, il ressemble donc à une grande collection de petits fichiers pour les liens logiciels et à une petite collection de gros fichiers pour les liens matériels.

Une mise en garde à ce type de cas d'utilisation est que dans les systèmes de fichiers qui utilisent COW, la modification de "l'original" pourrait casser les liens physiques, mais pas les liens logiciels. Mais, si l'intention est d'avoir la copie principale, après modification, enregistrée et triée, COW n'entre pas dans le scénario.

27
user207673

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, b est inutile. (Et ces étapes peuvent se produire 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.

23
Stephen Kitt

Un seul programme peut changer son 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

Lequel 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 concernés.

Cela permet de ne pas avoir à compiler (principalement) du code identique sur deux binaires (principalement) identiques. Gardez à l'esprit que les dates unix correspondent aux jours où l'espace disque était très cher, mais selon Stevens dans APUE chapitre 4, les liens symboliques ont été implémentés 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é comme nom de programme pourrait ressembler à quelque chose comme:

#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'
$
11
thrig

Lorsque mon logiciel P2P a fini de télécharger un certain fichier, le fichier est placé dans un répertoire spécifique. Les fichiers téléchargés n'ont presque jamais besoin d'être modifiés. Le cas commun 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 sur le réseau P2P comme je le devrais même si je rm ou mv la "copie".
  • Le fichier se trouve également sur le chemin où j'en ai besoin; la plupart de ces emplacements ne sont pas partagés.
  • Je peux rm l '"original" pour arrêter de partager le fichier; cette opération n'affecte pas la "copie" à l'endroit souhaité.
  • Mon espace disque n'est utilisé qu'une seule fois.

Le point principal: si je savais à l'avance quel fichier je ferais rm en premier, je pourrais aller avec un lien symbolique. Mais je ne sais jamais.

8
Kamil Maciorowski

Les systèmes de fichiers sont un moyen simple et pourtant efficace d'organiser et de classer les fichiers (c'est leur raison principale d'exister). Les liens physiques permettent une plus grande flexibilité dans ce domaine.

Comme mentionné, il n'y a pas de concept d'original et de copie 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 (pointez sur son inode) sans priorité, donc il n'y a pas non plus de liens durs cassés. .

Voici donc quelques-uns des cas d'utilisation qui les hardlinks sont présents mais les softlinks ne le sont pas:

  1. Imaginez que vous ayez une collection de films, de musique ou d'autres médias et que vous souhaitiez appliquer différents critères de classification, comme les 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. Toujours vous ne voulez pas dupliquer les fichiers ni décider où mettre "l'original" pour avoir la liberté de reclasser sans avoir à " gérer "et re-lier les fichiers lors du déplacement afin d'éviter les liens rompus.

  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 syscall chroot de bénéficier d’un sous-ensemble de fichiers à la racine du système de fichiers "maître" (liens symboliques n'a jamais pu référencer des fichiers extérieurs au sandbox chroot, même s'ils ont des chemins relatifs).

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

6
Marcelo

Exemple très courant dans le monde réel qui nécessite des liens physiques:

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 relie simplement en dur.

Tout référentiel peut supprimer un objet, mais l'inode reste valide pour le reste du référentiel. Et si un objet est supprimé de tous les dépôts, il est supprimé du disque. Les liens durs constituent une solution magnifiquement robuste et rapide. Très fréquent dans les serveurs CI.

Il existe une version non-hard-link: git clone --shared <repository>. Cependant, cela est capricieux et a beaucoup plus de réserves car tout le monde travaille sur le même répertoire.

5
Paul Draper

J'ai récemment eu un cas d'utilisation pour une procédure de mise à jour quelque peu sûre pour les systèmes basés sur U-Boot où uImage est un lien logiciel pointant vers l'image à démarrer, l'idée était qu'une panne de courant ne devrait poser aucun problème, non importe à quel moment du processus il se produit (en supposant que le système de fichiers joue):

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 physiques, ce ne serait pas aussi simple.

/Éditer:

Grâce aux commentaires je sais maintenant qu'il vaudrait mieux 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 rm est là pour pouvoir mieux échapper à un état étrange, par exemple si uImage est quelque chose d'inattendu qui ferait échouer mv [mais pas nécessairement le précédent ln -sf Solution].)

4
phk

BackupPC est un système de sauvegarde qui utilise des liens durs 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 qui utilise ce fichier crée un lien dur vers le fichier de pool. À mesure que les sauvegardes expirent/sont supprimées, leurs liens durs sont supprimés du système de fichiers.

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

Cette méthode présente certains inconvénients (principalement, 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 dans la 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 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 génération d'application et lui donner un nom de fichier descriptif (par exemple, avec un numéro de version ou une date). Vous ne pouvez pas créer un lien symbolique vers le fichier avec le "vrai" nom - vous devez créer un lien physique.

foo.war Lié à foo-20170129.war Ne fonctionne pas

foo.war Lié en dur à foo-20170129.war Fonctionne.

je n'aime pas ce comportement Tomcat, mais les liens durs me permettent de le contourner.

3
Dan Pritts

Une utilisation que j'ai eue pour les liens durs est lors du téléchargement ou de la décompression d'un fichier cassé. Le programme qui effectue le téléchargement ou la décompression (comme décompresser ou annuler) supprimera souvent automatiquement le fichier incomplet lorsqu'il rencontre une erreur, et il n'y a généralement pas d'option pour le conserver. Si je veux conserver le fichier, je peux y créer un lien physique.

3
Thomas Padron-McCarthy