C'è qualche differenza pratica tra l'utilizzo ln -so mount --bind?
Voglio spostare alcune cartelle in un'altra partizione, senza cambiare le impostazioni del demone, e mi chiedo quale approccio dovrei adottare.
Preferisco ln -spoiché richiede una configurazione minima (nessuna /etc/fstabmodifica), ma forse c'è un motivo per cui non è comune?
Risposte:
Diavolo sì. Se lo esegui ln -s, crei un collegamento simbolico, che è un inode che punta a un determinato oggetto filesystem, motivo per cui i collegamenti simbolici possono attraversare i filesystem e i collegamenti reali non possono: i collegamenti reali non hanno il loro inode.
Se monti un filesystem con --bind, crei un secondo mountpoint per un dispositivo o un filesystem.
Se immagini un link simbolico come reindirizzamento, allora immagina un --bindfilesystem montato come la creazione di un altro gateway per i dati.
I collegamenti simbolici e i bind mount sono un gioco di palla completamente diverso.
La --bindmontatura mi sembra un po 'più robusta e probabilmente è un po' più veloce rispetto al lavorare con un collegamento simbolico. D'altra parte, non ci sono seri inconvenienti nell'uso del collegamento simbolico, poiché l'hit di performance sarà piccolo (se esiste del tutto).
Modifica : ci ho pensato, e il colpo di scena potrebbe essere un po 'più grande di quanto pensassi inizialmente. Se si dispone di un'applicazione che legge molti file diversi, ogni nuovo file aperto richiederà una lettura aggiuntiva. Alcune ricerche qui suggeriscono che la mia ipotesi sia corretta, quindi se hai un'applicazione IO pesante in esecuzione lì, considera l' --bindopzione per montare sopra la soluzione symlink.
La ragione per cui non è comune, è probabilmente il fatto che un symlink è visibile in un ls, mentre un bind mount è visibile solo quando si guarda / proc / mounts o / etc / mtab (che è ciò che fa il comando mount, se lo è eseguito senza parametri). A parte questo, non credo ci siano problemi. Sarei interessato se ci fosse, però.
Aggiunta : un altro problema con ln -squello è che per alcune applicazioni, quando il percorso viene sottoposto a dereferenziazione, può causare il balk dell'applicazione se "si aspetta" che alcuni elementi si trovino in luoghi specifici.
mount, se invocato senza alcun argomento, stampa il contenuto di /etc/mtab, che ha informazioni leggermente diverse rispetto a /proc/mounts. (In particolare, /proc/mounts(link simbolico a /proc/self/mounts) mostra sempre i mountpoint visibili al processo leggendolo.)
Una delle grandi differenze tra ln -se un mount bind è che puoi usare un mount bind per "modificare" un filesystem di sola lettura. Ad esempio, se fosse montato un CD /mnt/applicatione si desidera sostituire /mnt/application/badconfigfile.confcon una versione corretta, è possibile effettuare questa operazione:
mount -o bind /path/to/correct/file.conf /mnt/application/badconfigfile.conf
Non sarebbe possibile influire sulla stessa modifica utilizzando un collegamento simbolico perché non è possibile modificare il filesystem di destinazione.
Questo può anche essere usato per avere un buon effetto se hai distribuito una suite di software comune tramite NFS (o una sorta di filesystem del cluster) e vuoi apportare modifiche specifiche dell'host su un sistema. È possibile semplicemente utilizzare un mount bind sul sistema di destinazione per sovrascrivere i file o le directory, se necessario.
Si potrebbe notare che come conseguenza dell'associazione a una montatura, che è essa stessa un'associazione, che è in seguito un rimbalzo, l'associazione originale rimane intatta, assumendo che tutto rimanga fisicamente connesso.
Cioè, se associa A a B e lega da B a C, e quindi lega da D a B, C sarà comunque associato ad A. Questo potrebbe essere quello che vuoi o no. Se si desidera che C segua B, rimontare usando gli stessi target, ovvero mount -o remount B C, oppure usare --rbindinvece. Non c'è --rebindopzione.