Come funziona Linux con collegamenti simbolici?

11

Voglio dire cosa sta succedendo quando un processo vuole leggere un link simbolico? Cosa succede quando qualcosa cambia un collegamento simbolico durante un processo di lettura o persino di scrittura?

Ad esempio: ho 2 enormi file simili da 100G /mnt/1e /mnt/2. /mnt/1è disponibile tramite il link simbolico /home/user/file. Alcuni programmi Ainiziano a leggere /home/user/file. E dopo un po 'qualcosa cambia il link da /mnt/1a /mnt/2, ma Asta ancora leggendo il file.

Il programma memorizza nella cache il percorso assoluto?

Avrà esito negativo ed errore, perché il collegamento simbolico è stato modificato o funzionerà correttamente, come se nulla fosse successo?

Differirà nel caso in cui /home/user/filesia collegato a un dispositivo a blocchi (ad esempio 2 dischi iscsi replicati)?

filesystems symlink

— corsa
fonte

9

Il collegamento simbolico punta al nome del file reale ( inode ) nel file system. Quando il sistema risolve quel link simbolico per trovare il file effettivo e aprirlo, trova e usa l'inode del file. A quel punto, il percorso che hai usato per arrivare al file non ha importanza. Ciò che il sistema operativo non memorizza nella cache, legge dal file dal suo inode. A quanto ho capito, potresti iniziare a leggere il file tramite un collegamento reale e rimuoverlo ~~(purché il file sia ancora collegato da qualche altra parte)~~ e non causerebbe problemi finché il file è stato risolto ( nome stringa-> inode).

— Kevin
fonte

4

Puoi rimuovere TUTTI i collegamenti al file e continuare a leggerlo una volta aperto. Questo è il motivo per cui è possibile aggiornare i pacchetti senza riavviare come è necessario su Windows; perché puoi rm il file eseguibile del programma anche se è in esecuzione.

— psusi,

1

@psusi So che i dati e l'inode sono ancora lì e non vengono più indicati, ma una volta che il file è stato eliminato, il sistema è libero di sovrascrivere quel punto sul disco, giusto? Quindi se il file è troppo grande per adattarsi alla cache dei file, come i file da 100 GB in questione, cosa succede se parte di essi viene sovrascritta prima di arrivare alla fine? Questo non è un problema per i file di sistema critici perché vengono caricati nella cache e mantenuti lì, ma 100 GB sono abbastanza grandi da pensare che questo possa essere un problema.

— Kevin,

2

Kevin, i file non sono stati rimossi dal disco fino alla fine dell'ultimo processo che utilizza il file. Puoi sempre trovare tutti i file che sono attualmente in uso in proc. Ma la tua risposta sembra spiegata alla mia domanda. Grazie.

— corsa il

2

Questa risposta manca un punto critico, che un link simbolico contiene il nome del file di destinazione.

— Keith Thompson,

6

Un collegamento simbolico è un piccolo file che contiene la posizione (ad es. Percorso e nome file) di un file di destinazione, con un flag nella voce della directory che indica che si tratta di un collegamento simbolico.

Quando si apre un collegamento simbolico, il sistema operativo seguirà la posizione per trovare il file di destinazione. Se la destinazione è essa stessa un collegamento simbolico, segue anche la sua posizione (1) (2) fino a quando la posizione punta a un file che non è un collegamento simbolico (chiamiamolo FinalFile ). Quindi il sistema operativo ottiene l' inode di FinalFile (l'inode contiene metadati come tempo di modifica e ha anche un puntatore ai dati del file). Finalmente viene aperto l'inode di FinalFile . D'ora in poi il processo utilizza quell'inode per leggere / scrivere nel file. Di conseguenza modificando il nome o il percorso del collegamento simbolico, eliminando il collegamento simbolico, modificando il percorso o il nome del file finale o persino eliminando il file finale(3) non ha alcun effetto sul processo; sta ancora leggendo dallo stesso inode.

Nella maggior parte dei casi le operazioni sui file di dati sul collegamento simbolico influiranno sul file finale (ad esempio, la lettura e la scrittura sul collegamento simbolico leggerà / scriverà sul file finale ) ma ci sono eccezioni: la readlink()chiamata di sistema legge il contenuto del collegamento simbolico stesso.

D'altra parte, le operazioni sui metadati dei file (come rinominare o eliminare) influiranno solitamente sul collegamento simbolico. Ma ci sono anche delle eccezioni: la lstat()chiamata di sistema è simile stat(), tranne per il fatto che restituisce informazioni sul link simbolico stesso piuttosto che su FinalFile (2).

(1) C'è un limite al numero di livelli e le cose diventano un po 'più complesse se la posizione nel collegamento simbolico è un percorso relativo.

(2) Leggi symlink (7): gestione simbolica del link per maggiori dettagli.man 7 symlink

(3) Il rmcomando o la unlink()chiamata di sistema non rimuove fisicamente un file. Rimuove la voce della directory che punta all'inode del file. Il file stesso viene rimosso solo se entrambi a) non ci sono più voci di directory (hard link) che fanno riferimento al suo inode eb) nessun processo ha il file aperto.

— Keith Thompson
fonte

1

Questo è quasi trasparente per Linux ed è molto più correlato al filesystem che stai usando rispetto al sistema operativo.

Non è un file normale o un file molto piccolo perché non è possibile creare un collegamento simbolico funzionante in una partizione VFAT, ad esempio semplicemente copiando il collegamento simbolico stesso su di esso, perché è registrato direttamente dal filesystem.

La differenza nel collegamento simbolico con un collegamento reale è che la nomina è verso un collegamento reale invece di passare ai settori di dati come fa un collegamento reale.

Esempio:

Test 1:

echo 'data' >file.txt

Questo creerà il file hard link.txt che punta ai settori da 10 a 20 * (* numeri solo per spiegazioni).

Test 2:

E se?

ln file.txt file_2.txt

Questo ha creato un hardlink file_2.txt che punta ai settori da 10 a 20 (lo stesso di file.txt), quindi se elimini file.txt, i settori da 10 a 20 sono ancora riservati e puoi vedere i dati all'interno di file_2.txt ... . (file.txt e file_2.txt sono entrambi come gli originali)

Test 3:

ln -s file.txt file_sym.txt

Collegamento simbolico puntato file_sym.txt al file hard file.txt, quindi quando provi ad accedere a file_sym.txt vedrai file.txt, ma se elimini file.txt file_sym non troverà più la destinazione.

Questi sono gestiti dal filesystem, ad esempio dai moduli ext4 per Linux (o se è compilato sul kernel), non importa se stai usando Linux o altri Unix.

— Luciano Andress Martini
fonte