Perché gli hard link sono validi solo all'interno dello stesso filesystem?

Sto leggendo questa introduzione alla riga di comando di Mark Bates.

Nel primo capitolo, afferma che i collegamenti fisici non possono estendersi ai file system.

Una cosa importante da notare sui collegamenti fisici è che funzionano solo sul file system corrente. Non è possibile creare un collegamento reale a un file su un file system diverso. Per fare ciò è necessario utilizzare collegamenti simbolici, Sezione 1.4.3.

Conosco solo un filesystem. Quello a partire da root ( /). Questa affermazione secondo cui i collegamenti reali non possono estendersi sui file system non ha senso per me.

Anche l' articolo di Wikipedia sui file system Unix non è utile.

Spero di poter rispondere in un modo che abbia senso per te. Un file system in Linux, è generalmente costituito da una partizione che è formattata in uno dei vari modi (devi scegliere amore!) In cui archiviare i file. Sia che i tuoi file di sistema, o i tuoi file personali ... siano tutti memorizzati su un file system. Questa parte ti sembra di capire.

Ma cosa succede se partizionate il vostro disco rigido per avere più di una partizione (pensate che Apple Pie sia a pezzi), o aggiungiate un disco rigido aggiuntivo (forse una chiavetta USB?). Per ragioni di argomento, hanno anche tutti i file system.

Quando guardi i file sul tuo computer, vedi una rappresentazione visiva dei dati sul file system della tua partizione. Ogni nome di file corrisponde a quello che viene chiamato un inode, che è dove vivono i tuoi dati, dietro le quinte. Un hard link consente di avere più "nomi file" (per mancanza di una descrizione migliore) che puntano allo stesso inode. Funziona solo se quei collegamenti fisici si trovano sullo stesso file system. Un collegamento simbolico punta invece al "nome file", che viene quindi collegato all'inode che contiene i tuoi dati. Perdona la mia rozza opera d'arte ma spero che questo spieghi meglio.

image.jpg             image2.jpg
          \           /
           [your data]

qui, image.jpg e image2.jpg puntano entrambi direttamente ai tuoi dati. Sono entrambi hardlink. Tuttavia...

image.jpg    <-----------  image2.jpg
           \ 
             [your data]

In questo esempio (approssimativo), image2.jpg non punta ai tuoi dati, punta a image.jpg ... che è un link ai tuoi dati.

I collegamenti simbolici possono funzionare oltre i confini del file system (supponendo che il file system sia collegato e montato, come la chiavetta USB). Tuttavia, un collegamento reale non può. Non sa nulla di ciò che è nell'altro file system o di dove sono archiviati i dati.

Speriamo che questo abbia più senso.

Il file system è composto da una struttura di directory composta da voci di directory per organizzare i file. Ogni voce della directory associa un nome file a un inode .

I collegamenti software ( simbolici ) sono voci di directory che non contengono dati, ma puntano semplicemente a un'altra voce (un file o una directory nello stesso file system o altro file system). E quando si elimina il file appuntito, il collegamento simbolico diventa inutilizzabile.

I collegamenti reali sono voci di directory che contengono il nome del file e il numero di inode . Quando si rimuove l'ultimo collegamento reale, non è più possibile accedere al file.

Conclusione:

Poiché l' inode è una struttura di dati utilizzata per rappresentare un oggetto file system, è interna al file system e non è possibile puntare a un inode di un altro file system.

Pertanto, gli hard link sono validi solo all'interno dello stesso file system, ma i soft link (collegamento simbolico) possono estendersi ai file system in quanto puntano semplicemente a un'altra voce della directory (l'interfaccia del file system e non un oggetto interno).

Il filesystem di root può essere composto da diversi filesystem; /usr/localpotrebbe essere montato su una partizione separata e /homepotrebbe essere su un'altra partizione su un disco di rete da qualche altra parte. In questo caso, /usr/local/bin/gitnon è possibile creare un collegamento reale per (ad esempio) al di fuori di /usr/local, perché si estenderebbe ai filesystem .

La ragione di ciò è che gli inode sono allocati separatamente per /, /usr/locale /home(di nuovo, in questo esempio), e quando si crea un collegamento reale si crea semplicemente un nome aggiuntivo per un inode.

I collegamenti duri hanno l'effetto di mantenere vivo il loro obiettivo. Finché è possibile raggiungere qualsiasi collegamento reale, il sistema assicurerà che la destinazione non possa essere rilasciata. È quindi necessario che tutti i supporti che potrebbero contenere collegamenti reali a un particolare inode vengano montati ogni volta che il sistema tenta di determinare se esistono riferimenti ad esso.

Dato che la durata dell'inode è di solito determinata mantenendo i conteggi dei riferimenti piuttosto che scansionare i riferimenti, potrebbe essere possibile organizzare le cose in modo che due o più file system che contenevano collegamenti tra loro possano essere usati indipendentemente a condizione che non sia necessario utilizzare collegamenti collegato tra i sistemi e purché non fosse necessario utilizzare fsck su nessuno dei due. Se l'inode conta su uno dei sistemi si è disturbato, tuttavia, l'unico modo per rendere di nuovo utile quel sistema sarebbe quello di utilizzare una forma di operazione fsck in grado di scansionare entrambi i file system alla ricerca di riferimenti. A causa di questo vincolo, mentre potrebbe essere possibile consentire a due file system interconnessi di essere utilizzabili in modo indipendente, i vantaggi di farlo sarebbero probabilmente troppo limitati per renderlo utile.

Un singolo numero di inode viene utilizzato per rappresentare il file in ciascun file system. Tutti gli hard link basati sul numero di inode. Link di riferimento al file system qui .