Я читал, что можно «размонтировать» диск, который в противном случае занят, используя опцию «ленивый». На странице руководства об этом сказано следующее:
umount - размонтирование файловых систем
-l Ленивое размонтирование. Отсоединить файловую систему от иерархии файловых систем сейчас и очистить все ссылки на файловую систему, как только она перестанет быть занятой. Эта опция позволяет размонтировать «занятую» файловую систему. (Требуется ядро 2.4.11 или более поздняя версия.)
Но какой в этом смысл? Я подумал, зачем мы вообще демонтируем разделы:
- Чтобы удалить оборудование
- Для выполнения операций с файловой системой, которые небезопасно выполнять во время монтирования
В любом из этих случаев, IMHO, все, что служит 'ленивому' размонтированию, это усложнить определение того, действительно ли диск размонтирован, и вы можете фактически продолжить эти действия. umount -lПохоже, единственное применение для неопытных пользователей - это 'чувствовать', что они достигли чего-то, чего на самом деле не достигли.
Зачем использовать ленивое размонтирование?
решение1
Допустим, вам действительно нужно изменить том, на котором программное обеспечение записывает журнал, например, веб-сервер, но у него большой трафик и его невозможно отключить для выполнения операции, а также нельзя изменить путь ведения журнала.
С помощью ленивого размонтирования вы можете безопасно размонтировать том, пока программное обеспечение все еще работает, смонтировать другой том в ту же точку монтирования и дать команду программному обеспечению повторно открыть файлы.
В идеале, поскольку вам не нужно было отключать программное обеспечение, не терялись никакие запросы и, по сути, не терялись никакие записи журнала, поскольку они продолжали записываться в старое монтирование до тех пор, пока файлы не были повторно открыты (насколько хорошо программное обеспечение справится с повторным открытием файлов, зависит от самого программного обеспечения).
Перефразируя страницу руководства, это означает, что если том имеет открытые файлы при ленивом размонтировании, на самом деле он остается смонтированным, но просто недоступен через файловую систему и по-настоящему размонтирован только после закрытия последнего открытого файла.
решение2
Потому что вы ленивы и хотите размонтировать диск после завершения операций с ним.
Вот вероятный сценарий:
Вы используете rsyncдля выполнения резервного копирования и уходите. Вы можете umount -lиспользовать диск, и как только он закончит копирование и синхронизацию, он отмонтируется, так что когда вы вернетесь после перерыва (который, как вы знаете, займет больше времени, чем резервное копирование), вы можете просто отключить диск, вместо того чтобы снова возиться с клавиатурой.
решение3
На самом деле это реализовано для того, чтобы сэкономить больше времени на выполнение последующих задач в рамках административных задач.
Если в конвейере ожидаются дополнительные задачи, независимые от этой, то можно выполнить ленивое размонтирование и продолжить работу с другими задачами в пакете.
Пример: Задача 1 и Задача 2 — это две административные задачи, запланированные одна за другой.
Задание 1Ежедневное резервное копирование
Эта команда копирует большое количество файлов из раздела проекта в резервный раздел, скажем, /mnt/backupProj, который будет смонтирован на лету и размонтирован в конце этой задачи. Копирование занимает значительное время.
Задание 2Обновление SQL-представлений
Выполняет серию обновлений представления базы данных на выделенном сервере.
Задача 2, очевидно, полностью независима от задачи 1, поэтому мы можем выполнить ленивое размонтирование /mnt/backupProj, не дожидаясь завершения задачи резервного копирования.
решение4
Рассмотрите вариант привязки, который вы можете увидеть при работе с chroot:
mount --rbind /proc /mnt/proc
# do stuff
umount /mnt/proc
Если у вас в системе есть демон, который постоянно опрашивает /proc(я смотрю на вас ksysguardd), то вы не сможете umount /mnt/proc. Lazy позволит вам umountв этом случае.