Perché esistono collegamenti reali?

So quali sono gli hard link, ma perché dovrei usarli? Qual è l'utilità di un hard link?

Il vantaggio principale degli hard link è che, rispetto ai soft link, non vi è alcuna penalità in termini di dimensioni o velocità. I soft link sono un ulteriore livello di indiretto oltre al normale accesso ai file; il kernel deve dereferenziare il collegamento quando si apre il file, e ciò richiede una piccola quantità di tempo. Il collegamento occupa anche una piccola quantità di spazio sul disco, per contenere il testo del collegamento. Queste penalità non esistono con hard link perché sono integrate nella struttura stessa del filesystem.

Il modo migliore che conosco per vedere questo è:

$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../

L' -iopzione per lsrenderlo ti dà il numero di inode del file. Sul sistema in cui ho preparato l'esempio sopra, mi è capitato di trovarmi in una directory con il numero di inode 1069765, ma il valore specifico non ha importanza. È solo un valore univoco che identifica un determinato file / directory.

Ciò che dice è che quando andiamo in una sottodirectory e guardiamo una diversa voce del filesystem chiamata .., ha lo stesso numero di inode che abbiamo ottenuto prima. Questo non accade perché la shell sta interpretando ..per te, come accade con MS-DOS e Windows. Su filesystem Unix ..c'è una vera voce di directory; è un collegamento reale che rimanda alla directory precedente.

Gli hard link sono i tendini che legano insieme le directory del filesystem. C'era una volta, Unix non aveva collegamenti reali. Furono aggiunti per trasformare il file system flat originale di Unix in un filesystem gerarchico.

(Per ulteriori informazioni, vedi Perché '/' ha una voce '..'?. )

È anche in qualche modo comune sui sistemi Unix che diversi comandi diversi siano implementati dallo stesso eseguibile. Non sembra essere il caso in Linux più, ma sui sistemi che ho usato in passato, cp, mve rmsono stati tutti lo stesso eseguibile. Ha senso se ci pensi: quando sposti un file tra i volumi, si tratta effettivamente di una copia seguita da una rimozione, quindi mvdovevo già implementare le funzioni degli altri due comandi. L'eseguibile può capire quale operazione fornire perché gli viene passato il nome da cui è stata chiamata.

Un altro esempio, comune nei Linux integrati, è BusyBox , un singolo eseguibile che implementa dozzine di comandi.

Dovrei sottolineare che sulla maggior parte dei filesystem, agli utenti non è consentito creare collegamenti fisici alle directory. Le voci .e ..sono gestite automaticamente dal codice del filesystem, che di solito fa parte del kernel. La restrizione esiste perché è possibile causare seri problemi al filesystem se non si è attenti a come si creano e si utilizzano i collegamenti diretti alla directory. Questo è uno dei tanti motivi per cui esistono collegamenti soft; non comportano lo stesso rischio.

Un utilizzo di hardlink che è estremamente utile è nei backup incrementali combinati con rsync. Risparmia molto spazio e semplifica notevolmente la procedura di restauro. Uso questo approccio per il backup nei miei server.

Prenditi del tempo per leggere questa spiegazione .

Se dopo aver letto quella pagina di Wikipedia la tua domanda è "perché dovrei mai usarli", allora non capisci quali siano i collegamenti.

Un collegamento è una voce della directory che punta ai blocchi sul disco. In altre parole, ogni file sul tuo sistema ha almeno un link. Quando si rmesegue un file, la chiamata di sistema effettiva è unlink(). Rimuove la voce della directory. I blocchi sul disco non sono cambiati ma il collegamento è sparito, quindi il file è stato rimosso dall'elenco delle directory.

Personalmente potresti non usare mai hard link, ma sono in tutto il tuo sistema. Per esempio:

$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzip2

Si può vedere che bunzip2, bzcate bziptutti usano lo stesso inode. In sostanza, è un file con tre nomi. Si potrebbe avere tre copie del file, ma perché? Utilizzerebbe solo inutilmente spazio su disco.

Ci sono un numero qualsiasi di usi. Li uso per creare blocchi basati su file. La chiamata di sistema link (2) è atomica, a differenza della maggior parte delle altre chiamate di sistema.

Un altro uso è all'interno di rsnapshot, in cui i backup vengono eseguiti nel tempo utilizzando collegamenti reali per ridurre la quantità di spazio su disco. Se un file non è stato modificato, il file è collegato alle istanze precedenti del file, i file modificati vengono copiati nuovamente.

Li uso anche per scambiare i file di configurazione sui server:, rm file.cfg && ln ~/tmp/file.cfg file.cfgquindi i file ~ / tmp / * possono essere eliminati in modo sicuro.

Da aggiungere alle numerose buone discussioni già presenti ...

• Il modo in cui l'accesso alle risorse per i programmi è implementato in unix (ovvero "tutto è un file" ), significa che l'infrastruttura per la gestione di più riferimenti a un file è necessaria affinché il sistema operativo funzioni, quindi non ci sono costi aggiuntivi qui.
• Il modo in cui le directory sono state implementate nei filesystem unix originali (ovvero un elenco di (inode, name)coppie di formati fissi significa che non ci sono costi aggiuntivi nel filesystem per avere hardlink (beh, fintanto che impediamo i cicli impedendo hardlinke alle directory (diverso da .e ..(questo inizia a sembrare un po 'di piacere per qualcun altro?)))

quindi li otteniamo gratuitamente.

Probabilmente dovrei coprire uno scenario trabocchetto di collegamenti reali . Un collegamento reale sarà lo stesso file con un nome diverso e / o una posizione diversa purché esista il file collegato originale . Non è nemmeno corretto pensare al file come "originale": entrambi sono voci di directory a sé stanti ed entrambi (o più) sono tutti uguali peer. Per file di lunga durata, questa potrebbe essere una benedizione, ma se una coppia viene eliminata e quindi creata, anche con lo stesso nome e contenuto, i file si separeranno.

Supponiamo di aver creato un /foo/myfilecollegamento hardlink a /repo/myfile. Entrambi sono puntatori agli stessi dati del file; cambia uno, l'altro cambia. Ma supponiamo che /repocapiti di contenere un repository Git. Se si verifica un ramo che non contiene myfileal suo interno, /repo/myfileviene eliminato. In questo momento, /foo/myfilediventa una semplice copia di /repo/myfile, com'era nel momento in cui l'altro della coppia era scollegato. È facile non notare nemmeno quando si passa da un ramo all'altro che il repertorio di file cambia, ma, quando si verifica il ramo originale, un nuovo file/repo/myfileè stato creato da Git. Se non prestassi attenzione, ti chiederesti perché i due file ora hanno contenuti diversi, anche se è facile fare il grok, poiché la relazione di collegamento tra i file non ha idea dei loro nomi. Al contrario, un soft link sopravviverebbe attraverso questo ciclo di eliminazione-creazione.

D'altra parte, il software che utilizza hard link ne è perfettamente consapevole e Git ne è un ottimo esempio. Git clona un repository sullo stesso filesystem quasi gratuitamente, perché utilizza collegamenti fissi per impostazione predefinita invece di copiare i file. Per Git, l'hard link è un caso d'uso perfetto, perché i suoi file oggetto e pacchetto non cambiano mai, quindi un clone del repository non modificherà mai l'altro (Git non conosce i file modificabili dell'hard link), e qualsiasi clone può essere cancellato senza alcuna precauzione: non è necessario tenere traccia di quale sia "originale" e contenga effettivamente i file: uno qualsiasi dei collegamenti reali è un partner uguale e "contiene" il file completo. I soft link non funzionerebbero qui.

Un altro vantaggio del collegamento reale è che qualsiasi collegamento può essere spostato senza interrompere l'accesso al contenuto del file. Con i collegamenti software, lo spostamento del file originale rende penzolanti tutti i collegamenti software.

La linea di fondo è che in molti casi d'uso entrambi i tipi di collegamento funzionano ugualmente bene, ma in alcuni l'uno o l'altro tipo è vantaggioso. L'efficienza, menzionata in molte risposte qui, è probabilmente una piccola preoccupazione per le macchine e i filesystem moderni, a meno che non si stia scavando un filesystem su un chip FLASH di un controller incorporato scadente. Le differenze funzionali sono più importanti e di solito dettano i vincoli ingegneristici e la scelta definitiva:

• L'hard link "source" può essere spostato in modo sicuro, mentre il soft link si interromperà.
• L'hard link è indistinguibile dal file da cui era collegato e il file è attivo fintanto che uno qualsiasi degli hard link è attivo; il soft link è asimmetrico.
• Il peer hard-link uscirà dal gruppo collegato se cancellato e ricreato, ma il soft link non perde il suo target.
• Il soft link può attraversare i filesystem, il hard link no.
• Il soft link può puntare a una directory, il hard link di solito non può (e praticamente non dovrebbe sempre).

Inoltre, devo indicare che la chiamata in libreria che elimina un file viene chiamata unlink()per un motivo! Ogni voce della directory è solo un hard link inizialmente singolare al suo inode.