Lazy umount o Desmontar un disco ocupado en Linux


19

He leído que es posible 'desmontar' un disco que de otro modo está ocupado utilizando la opción 'perezosa'. La página de manual tiene esto que decir al respecto:

umount - desmontar sistemas de archivos

-l perezosa desmontar. Separe el sistema de archivos de la jerarquía del sistema de archivos ahora y limpie todas las referencias al sistema de archivos tan pronto como ya no esté ocupado. Esta opción permite desmontar un sistema de archivos "ocupado". (Requiere el kernel 2.4.11 o posterior).

Pero, ¿cuál sería el punto en eso? Pensé por qué desmontamos las particiones:

  1. Para quitar el hardware
  2. Para realizar operaciones en el sistema de archivos que no sería seguro hacer mientras está montado

En cualquiera de estos casos, todo un desmontaje 'perezoso' sirve en mi humilde opinión para que sea más difícil determinar si el disco realmente está desmontado y realmente puede continuar con estas acciones. La única aplicación para umount -lparece ser que los usuarios sin experiencia se sientan como si hubieran logrado algo que no han logrado.

¿Por qué usarías un desmontaje perezoso?

Respuestas:


10

Debido a que es perezoso, desea desmontar después de realizar las operaciones de disco.

Aquí hay un escenario plausible:

Estás utilizando rsyncpara realizar tus copias de seguridad y alejarte. Puede umount -lmanejar la unidad y una vez que termine de copiar y sincronizar, se desmonta, de modo que cuando regrese después de un descanso (que sabe que tomará más tiempo que la copia de seguridad) simplemente puede desconectar la unidad en lugar de tener que volver a tocar el teclado .


Si fuera flojo, seguramente querría ahorrar MÁS tiempo al no tener que usar el argumento, porque una vez que regresó, sabía que podía desmontarlo inmediatamente ahora que la copia de seguridad ha terminado. ¿O hacer que desmontar la unidad sea parte de las operaciones posteriores a la copia de seguridad?
deed02392

Piénselo de esta manera: el disco ya no está ocupado, desmóntelo ahora. Ya no está montado, por lo que nada más puede escribirle. Es "haz esto cuando puedas" en lugar de equivocarte.
Broam

Entonces, ¿cómo saber cuándo se realizan las operaciones de disco? Vea este ejemplo (¿error?) De poder escribir un archivo en un sistema de archivos ya desmontado
Tom Hale

5

Esto se implementa realmente para ganar más tiempo para realizar tareas de seguimiento en tareas administrativas.

Si hay más tareas, independientes de esta, esperando en la tubería, entonces puede desmontar perezosamente y continuar con otros en el lote.

Ejemplo : la Tarea 1 y la Tarea 2 son dos tareas administrativas programadas consecutivamente.

Tarea 1 Copia de seguridad diaria

Éste copia una gran cantidad de archivos de una partición de proyecto a una partición de respaldo, por ejemplo, / mnt / backupProj, que se montará sobre la marcha y se desmontará al final de esta tarea. La copia lleva un tiempo considerable.

Tarea 2 Actualizar vistas SQL

Realiza una serie de actualizaciones de vista de base de datos en un servidor dedicado.

La Tarea 2 es obviamente completamente independiente de la Tarea 1, por lo que podemos desmontar / mnt / backupProj sin esperar a que se complete la tarea de copia de seguridad.


1
¿Puede dar un ejemplo? ¿En qué situación 'ganaría / ahorraría tiempo'?
escritura 02392

4

Utilizo lazy umount en los casos en que obviamente se atascó por varias razones (como el servidor nfs inactivo), también cuando necesito ver el contenido original del directorio que fue montado por el montaje. En ambos casos, la montura está ocupada. Creo que hay otros casos extremos, pero estos 2 son los motivos más comunes por los que utilicé la opción.


El recomienda --forcepara el caso de NFS.
Tom Hale

3

Considere un montaje de unión como podría ver cuando trabaje con chroot:

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

Si tienes un demonio en tu sistema que constantemente te interroga /proc(te estoy mirando ksysguardd), entonces no podrás umount /mnt/proc. Lazy te dejará umounten este caso.


¿Por qué no usar --forceaquí en su lugar?
Tom Hale

2

Las unidades USB a veces se bloquean debido a fallas de hardware. Incluso si vuelve a conectar la unidad físicamente, obtiene otro nombre de dispositivo. El antiguo nombre del dispositivo no se puede desmontar normalmente. cantidad -l obligó a la entrada muerta a desaparecer.


1

Digamos que realmente necesita cambiar el volumen en el que un software escribe un registro, por ejemplo, un servidor web, pero tiene mucho tráfico y no se puede desactivar para la operación ni se puede cambiar la ruta de registro.

Con el desmontaje diferido, puede desmontar de manera segura el volumen mientras el software aún se está ejecutando, montar otro volumen en el mismo punto de montaje y ordenar al software que vuelva a abrir los archivos.

Idealmente, dado que no era necesario apagar el software, no se perdieron solicitudes y tampoco se perdieron entradas de registro, ya que todavía se escribían en el soporte antiguo hasta que se volvían a abrir los archivos (qué tan bien maneja el software la reapertura del archivos depende del software).

Parafraseando la página de manual, significa que si el volumen tiene archivos abiertos cuando está vago desmontado, en realidad permanece montado pero simplemente no es accesible a través del sistema de archivos y solo se desmonta realmente cuando se cierra el último archivo abierto.


1
Gracias, esto suena como una aplicación útil. ¿ lsofMostrará archivos abiertos en el antiguo punto de montaje? También me pregunto cómo diferenciaría los archivos abiertos en el volumen anterior y en el nuevo.
escritura 02392

0

Utilizo encfs para cifrar parte de mis datos confidenciales.

Cuando se monta el disco, nautilus crea vistas previas (creo, no estoy seguro) y bloquea los archivos. Cuando quiero desmontarlo, dice que está bloqueado por otro proceso.

Al desmontarlo perezosamente, la carpeta desaparece de mi jerarquía y queda oculta. Y cuando finaliza el proceso en segundo plano, se desmonta con éxito.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.