Lazy umount o Smontaggio di un disco occupato in Linux


19

Ho letto che è possibile 'smontare' un disco che è altrimenti occupato usando l'opzione 'pigro'. La manpage ha questo da dire al riguardo:

umount - smonta file system

-l Smontaggio pigro. Scollega subito il filesystem dalla gerarchia del filesystem e ripulisci tutti i riferimenti al filesystem non appena non è più occupato. Questa opzione consente di smontare un filesystem "occupato". (Richiede il kernel 2.4.11 o successivo.)

Ma quale sarebbe il punto in questo? Ho considerato il motivo per cui smontiamo le partizioni:

  1. Per rimuovere l'hardware
  2. Per eseguire operazioni sul filesystem che non sarebbero sicure da fare durante il montaggio

In uno di questi casi, tutto uno smontaggio 'pigro' serve a IMHO per rendere più difficile determinare se il disco è veramente smontato e si può effettivamente procedere con queste azioni. L'unica domanda per gli umount -lutenti inesperti sembra essere quella di "sentirsi" come se avessero realizzato qualcosa che non avevano.

Perché dovresti usare un smontaggio pigro?

Risposte:


10

Perché sei pigro: vuoi smontare dopo aver completato le operazioni del disco.

Ecco uno scenario plausibile:

Stai usando rsyncper eseguire i tuoi backup e andartene. È possibile umount -ll'unità e una volta terminata la copia e la sincronizzazione, si smonta, in modo che quando torni dopo una pausa (che sai richiederà più tempo del backup) puoi semplicemente scollegare l'unità invece di dover giocherellare di nuovo con la tastiera .


Se fossi pigro, sicuramente vorresti risparmiare PIÙ tempo senza dover usare l'argomento, perché una volta tornato sapevi che potresti smontarlo immediatamente ora che il backup è terminato? O fare smontare l'unità parte delle operazioni post-backup?
deed02392,

Pensala in questo modo: il disco non è più occupato - smontalo ora. Non è più montato, quindi nient'altro può scrivergli. È "fallo quando puoi" invece di sbagliare.
Broam,

Quindi, come fai a sapere quando le operazioni del disco sono state fatte? Vedi questo esempio (bug?) Di poter scrivere un file su un filesystem già smontato
Tom Hale,

5

Questo è effettivamente implementato per guadagnare più tempo per svolgere attività di follow-up in attività amministrative.

Se ulteriori attività, indipendentemente da questa, sono in attesa nella pipeline, è possibile smontare-smontare e proseguire con gli altri nel batch.

Esempio : l'attività 1 e l'attività 2 sono due attività amministrative programmate schiena contro schiena.

Attività 1 Backup giornaliero

Questo copia un gran numero di file da una partizione di progetto a una partizione di backup, diciamo, / mnt / backupProj, che verrà montato al volo e smontato alla fine di questa attività. La copia richiede molto tempo.

Attività 2 Aggiorna viste SQL

Esegue una serie di aggiornamenti per la visualizzazione del database su un server dedicato.

L'attività 2 è ovviamente completamente indipendente dall'attività 1, quindi possiamo pigiare-smontare / mnt / backupProj senza attendere il completamento dell'attività di backup.


1
Potete fornire un esempio? In quale situazione "guadagnerebbe / risparmierebbe tempo"?
deed02392,

4

Uso lazy umount nei casi in cui era ovviamente bloccato per vari motivi (come il server nfs inattivo), anche quando ho bisogno di vedere il contenuto originale della directory che è stata montata dal mount. In entrambi i casi la montatura è occupata. Penso che ci siano altri casi limite, ma questi 2 sono i motivi più comuni per cui ho usato l'opzione.


Si consiglia --forceper il caso NFS.
Tom Hale,

3

Prendi in considerazione un attacco bind come potresti vedere quando lavori con chroot:

mount --rbind /proc /mnt/proc
# do stuff
umount /mnt/proc

Se hai un demone sul tuo sistema che interroga costantemente /proc(ti guardo ksysguardd), non sarai in grado umount /mnt/proc. Lazy ti lascerà umountin questo caso.


Perché non usare --forcequi invece?
Tom Hale,

2

Le unità USB a volte si bloccano a causa di un guasto hardware. Anche se ricolleghi fisicamente l'unità, ottieni un altro nome dispositivo. Il vecchio nome dispositivo non può essere smontato normalmente. quantità -l ha costretto a svanire l'ingresso morto.


1

Supponiamo che tu abbia davvero bisogno di cambiare il volume su cui un software sta scrivendo un registro, ad esempio un web server, ma ha molto traffico e non può essere disattivato per l'operazione né è possibile modificare il percorso di registrazione.

Con lazy smontaggio, puoi smontare in sicurezza il volume mentre il software è ancora in esecuzione, montare un altro volume sullo stesso mountpoint e comandare al software di riaprire i file.

Idealmente, poiché non è stato necessario disattivare il software, non sono state perse richieste e sostanzialmente non sono state perse voci di registro, poiché erano ancora in fase di scrittura sul vecchio supporto fino alla riapertura dei file (in che modo il software gestisce la riapertura del i file dipendono dal software).

Parafrasando la manpage, significa che se il volume ha file aperti quando è pigro smontato, in realtà rimane montato ma non accessibile attraverso il filesystem e viene smontato solo quando l'ultimo file aperto viene chiuso.


1
Grazie sembra un'utile applicazione. Mostrerà lsofi file aperti sul vecchio mountpoint? Inoltre mi chiedo come sarebbe differenziare i file aperti sul vecchio volume e su quello nuovo?
deed02392

0

Uso encfs per crittografare parte dei miei dati sensibili.

Quando il disco è montato, nautilus crea anteprime (penso, non ne sono sicuro) e blocca i file. Quando voglio smontarlo, dice che è bloccato da un altro processo.

Smontandolo smontando, la cartella scompare dalla mia gerarchia ed è nascosta. E quando termina il processo in background, viene smontato con successo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.