Quando sarebbe utile creare un collegamento reale?

Esistono sostanzialmente due limiti principali con collegamenti reali:

1. I collegamenti fissi normalmente richiedono che il collegamento e il file risiedano nello stesso file system.
2. Solo il superutente può creare un collegamento reale a una directory.

Pertanto, sono stati introdotti collegamenti simbolici per aggirare i limiti degli hard link. Quindi, la domanda è: sono ancora necessari hard link? Potrebbe esserci una situazione in cui sono più utili?

I collegamenti fisici ci aiutano a organizzare il nostro file system in un modo molto più flessibile. Fondamentalmente, i collegamenti fisici ci consentono di prendere un file e avere più posizioni contemporaneamente nel filesystem. Pensa a uno scenario in cui sei un fotografo e hai molte foto (questo è un esempio della mia vita!). Potresti organizzarli in base alle persone che compaiono in essi, perché a volte le persone ti chiedono delle foto. Ma potresti anche voler organizzarli in base alla posizione e alla data. Non c'è modo reale di nidificare queste tre cose, sono assi dell'organizzazione totalmente separati. Quindi puoi creare tre diverse gerarchie per queste tre cose diverse e avere ogni foto presente in tutte e tre, senzadover conservare ogni foto tre volte. Questa è la magia degli hardlink. Scollegando i collegamenti simbolici, non dobbiamo preoccuparci di dove sia il "file reale", perché sono tutti i file reali. Possiamo eliminare e spostare a piacimento, perché il file verrà conservato fino a quando non ci saranno più riferimenti ad esso, e rimosso quando si elimina l'ultimo collegamento. È semplice e non richiede di tenere traccia di molto.

Il contenuto di un file non verrà eliminato fino a quando tutti i collegamenti reali (sì, tutti i nomi di file sono collegamenti fissi, anche il primo) non saranno stati cancellati e il file chiuso. Come tale, può essere utile quando un file è richiesto in più posizioni, ma può essere rimosso da uno di essi in qualsiasi momento, ad esempio tra ~/Downloads/coolsong.mp3e ~/Music/Cool Song.mp3.

Un vantaggio non molto importante di un hard link rispetto a un link simbolico è che quando raggiunge l'inode per un hard link, il kernel non ha ulteriori elaborazioni da fare per accedere al file. Quando incontra un collegamento simbolico, il kernel deve leggere il valore del collegamento e continuare a attraversare la struttura della directory prima di raggiungere l'inode per il file. Questo richiede più tempo, sebbene la differenza non sia necessariamente misurata facilmente. Diventa davvero divertente quando uno degli elementi sul valore del collegamento simbolico è esso stesso un collegamento simbolico.

ci sono diverse ragioni per i collegamenti reali

1. mantenere i riferimenti a un file fino a quando l'ultimo riferimento è sparito (come ha sottolineato Ignacio)
2. quando si collegano i file hard link, occupano solo lo spazio di un file nel file system (entrambi i riferimenti al file condividono gli stessi i-nodi). Pertanto, gli hard link devono trovarsi sullo stesso file system.

Quindi un motivo per utilizzare i collegamenti reali è probabilmente quello di risparmiare molto spazio ...

È possibile aggiungere uno dei riferimenti e i dati vanno nel file condiviso. Puoi anche aggiungere a un descrittore di file mentre leggi dall'altro (ad es. Con tail -f)

Molti degli esempi forniti qui sono validi, ma funzionano ugualmente bene con i collegamenti software (ad esempio il problema "è necessario un file in più posizioni").

Un bell'esempio per cui gli hard link sono davvero utili è il software di backup Dirvish :

Dirvish è un sistema di backup di rete rapido, basato su disco e rotante.

Con dirvish puoi mantenere un set di immagini complete dei tuoi filesystem con creazione e scadenza incustodite. Un deposito di backup sporco è come una macchina del tempo per i tuoi dati.

Dirvish crea backup a livello di filesystem (ovvero copia i file, non crea immagini), copiando i file su un filesystem separato (backup) (come un disco rigido USB). Ogni volta che si esegue un backup, dirvish creerà una copia separata e completa dell'albero delle directory da salvare.

Il trucco è che se dirvish rileva che esiste già una copia di backup precedente dell'albero che stai salvando, riutilizzerà automaticamente i file che non sono stati modificati, creando un collegamento reale nel nuovo albero al file nel vecchio albero.

In questo modo, ogni copia di backup è una copia completa e autonoma dell'albero delle directory, ma allo stesso tempo solo i file modificati occupano effettivamente spazio nel file system. In altre parole, si ottengono contemporaneamente i vantaggi di backup incrementali (risparmio di spazio) e backup completi (facile recupero).

Questo è possibile solo perché i collegamenti fisici sono completamente trasparenti agli strumenti dello spazio utente.

Questo probabilmente funzionerebbe anche con i collegamenti simbolici (sebbene si verifichino problemi durante il backup dei dati che utilizzano collegamenti simbolici stessi), ma un vantaggio possibile solo con i collegamenti reali è:

Se si desidera eliminare i vecchi backup, è possibile eliminare semplicemente la struttura di directory di backup corrispondente. I file collegati solo da quell'albero vengono eliminati automaticamente dal filesystem (perché il loro ultimo collegamento reale viene eliminato), ma i file che appaiono anche in altre copie rimangono sul disco.

Un caso utile è, ad esempio, quando si dispone di un programma (o script) che deve scaricare un tarball temporaneo di grandi dimensioni e dopo averlo estratto il programma lo cancellerà immediatamente.

Se per qualche motivo vuoi conservare quel tarball per un uso futuro, il modo migliore per farlo è ln /tmp/tarball.tgz ~mentre il tarball è ancora in fase di download. Quindi non devi fare nulla.

Al termine del download e anche dopo che il programma ha eliminato quello "originale", la copia esatta dovrebbe essere ancora nella directory home.

Uso "Hard Link" per eseguire il backup di alcuni dei miei "HowTos" e frammenti

Ho una directory denominata "Documenti condivisi" nel mio utente / root. In quella directory ho "hard link" ai miei consigli, trucchi, frammenti, howto che vivono nelle loro directory appropriate; php, mysql, css, regex, formule, linux, ecc., Avendoli in un 'unico posto' rende molto più facile da usare, aggiornali che dover saltare nei miei Documenti / directory alla ricerca di questi documenti che uso spesso.

Molto tempo fa ho usato i symlink. Farei fedelmente il backup di questa directory comune 'Documenti condivisi' sul mio server. Il problema è, symlink o 'Soft Links', se copiato (cp -auv) o tar 'e copiato, copiare SOLO il' link 'e NON il contenuto del documento. Quindi, dovrei attraversare le directory e copiare ciascuna delle 2 dozzine di file dalla loro posizione attuale.

Con HARD LINKS, posso copiare, tarare, sincronizzare di nuovo la directory "Documenti condivisi" e fare il backup dei documenti ampiamente dispersi in tutta sicurezza, il contenuto viene effettivamente eseguito il backup. Mi ha davvero fatto schifo, quando mi sono reso conto che avrei eseguito il backup di 0 "file di collegamento" e non delle informazioni.

Unico inconveniente dell'uso di 'Hard Links' è che fare ls in una directory non ti dà un'indicazione che un file sia 'collegato' con un altro file o dove quel file possa coesistere. Ci sono modi per trovarli, ma sto dicendo che non è ovvio con un semplice ls -l -> punta a ... Quindi, di solito aggiungo una nota all'inizio del documento che indica quale directory / file 'questo file 'è' condiviso 'con

Landis.