He leído que es posible "desmontar" un disco que de otro modo estaría ocupado utilizando la opción "lazy". La página de manual tiene esto que decir al respecto:
umount - desmontar sistemas de archivos
-l Desmontaje diferido. 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 kernel 2.4.11 o posterior).
¿Pero qué sentido tendría eso? Consideré por qué desmontamos particiones:
- Para quitar el hardware
- Para realizar operaciones en el sistema de archivos que no serían seguras mientras está montado
En cualquiera de estos casos, lo único que sirve un desmontaje "perezoso" en mi humilde opinión es hacer que sea más difícil determinar si el disco realmente está desmontado y si realmente puede continuar con estas acciones. La única aplicación umount -lparece ser que los usuarios sin experiencia "sientan" que han logrado algo que no han logrado.
¿Por qué usarías un desmontaje diferido?
Respuesta1
Supongamos 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 el volumen de forma segura mientras el software aún se está ejecutando, montar otro volumen en ese mismo punto de montaje y ordenarle al software que vuelva a abrir los archivos.
Idealmente, como no era necesario apagar el software, no se perdieron solicitudes y esencialmente tampoco se perdieron entradas de registro, ya que todavía se escribían en el soporte anterior hasta que se volvieron a abrir los archivos (qué tan bien maneja el software la reapertura del archivo). archivos depende del software).
Parafraseando la página de manual, significa que si el volumen tiene archivos abiertos cuando se desmonta de forma diferida, 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.
Respuesta2
Porque eres vago: quieres desmontarlo una vez finalizadas las operaciones del disco.
He aquí un escenario plausible:
Estás utilizando rsyncpara realizar tus copias de seguridad y alejarte. Puede acceder umount -la la unidad y, una vez que haya terminado de copiar y sincronizar, se desmonta, de modo que cuando regrese después de un descanso (que sabe que llevará más tiempo que la copia de seguridad) pueda simplemente desconectar la unidad en lugar de tener que volver a manipular el teclado. .
Respuesta3
En realidad, esto se implementa para ganar más tiempo para realizar tareas de seguimiento en tareas administrativas.
Si hay más tareas, independientemente de esta, esperando en proceso, entonces puede desmontarlas de forma diferida y continuar con otras en el lote.
Ejemplo: La Tarea 1 y la Tarea 2 son dos tareas administrativas programadas consecutivamente.
Tarea 1Copia de seguridad diaria
Este copia una gran cantidad de archivos de una partición de proyecto a una partición de respaldo, digamos, /mnt/backupProj, que se montará sobre la marcha y se desmontará al final de esta tarea. La copia lleva una cantidad significativa de tiempo.
Tarea 2Actualizar vistas SQL
Realiza una serie de actualizaciones de la vista de la 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 de forma diferida sin esperar a que se complete la tarea de copia de seguridad.
Respuesta4
Considere un montaje de enlace como podría ver al trabajar con chroot:
mount --rbind /proc /mnt/proc
# do stuff
umount /mnt/proc
Si tienes un demonio en tu sistema que interroga constantemente /proc(te estoy mirando ksysguardd), entonces no podrás umount /mnt/proc. Lazy te dejará umounten este caso.