'lazy' 옵션을 사용하면 사용 중인 디스크를 '마운트 해제'할 수 있다는 내용을 읽었습니다. 맨페이지에는 이에 대해 다음과 같은 내용이 나와 있습니다.
umount - 파일 시스템 마운트 해제
-l 게으른 마운트 해제. 지금 파일 시스템 계층에서 파일 시스템을 분리하고 더 이상 사용되지 않는 즉시 파일 시스템에 대한 모든 참조를 정리하십시오. 이 옵션을 사용하면 "사용 중인" 파일 시스템을 마운트 해제할 수 있습니다. (커널 2.4.11 이상이 필요합니다.)
하지만 그게 무슨 의미가 있겠습니까? 파티션을 분리하는 이유를 고려했습니다.
- 하드웨어를 제거하려면
- 마운트된 동안 수행하기 안전하지 않은 파일 시스템에서 작업을 수행하려면
두 경우 모두 IMHO에서 제공하는 모든 '지연' 마운트 해제는 디스크가 실제로 마운트 해제되었는지 확인하고 실제로 이러한 작업을 진행할 수 있는지 확인하기 어렵게 만드는 것입니다. 의 유일한 응용 프로그램은 umount -l경험이 부족한 사용자가 자신이 아직 달성하지 못한 것을 달성한 것처럼 '느끼는' 것 같습니다.
게으른 마운트 해제를 사용하는 이유는 무엇입니까?
답변1
소프트웨어가 로그를 기록하는 볼륨(예: 웹 서버)을 실제로 변경해야 하지만 트래픽이 많아 작업을 위해 끌 수 없고 로깅 경로를 변경할 수 없다고 가정해 보겠습니다.
지연 마운트 해제를 사용하면 소프트웨어가 계속 실행되는 동안 볼륨을 안전하게 마운트 해제하고, 동일한 마운트 지점에 다른 볼륨을 마운트하고, 소프트웨어에 파일을 다시 열도록 명령할 수 있습니다.
이상적으로는 소프트웨어를 끌 필요가 없었기 때문에 요청이 손실되지 않았고 기본적으로 로그 항목도 손실되지 않았습니다. 왜냐하면 파일이 다시 열릴 때까지 이전 마운트에 계속 기록되고 있었기 때문입니다(소프트웨어가 파일 다시 열기를 얼마나 잘 처리하는지). 파일은 소프트웨어에 달려 있습니다).
맨페이지를 다르게 표현하면, 지연 마운트 해제 시 볼륨에 열린 파일이 있는 경우 실제로는 마운트된 상태로 유지되지만 파일 시스템을 통해 액세스할 수 없으며 마지막 열린 파일이 닫힐 때만 실제로 마운트 해제된다는 의미입니다.
답변2
당신은 게으르기 때문에 디스크 작업이 완료된 후 마운트를 해제하려고 합니다.
그럴듯한 시나리오는 다음과 같습니다.
rsync백업을 수행하고 떠나는 데 사용하고 있습니다 . 드라이브를 사용할 수 umount -l있고 복사 및 동기화가 완료되면 마운트가 해제되므로 휴식 후(백업보다 시간이 더 오래 걸릴 것임을 알고 있음) 다시 돌아올 때 키보드를 다시 만지작거리는 대신 드라이브를 분리하기만 하면 됩니다. .
답변3
이는 실제로 관리 작업에서 후속 작업을 수행하는 데 더 많은 시간을 확보하기 위해 구현됩니다.
이 작업과 별개로 추가 작업이 파이프라인에서 대기 중인 경우 지연 마운트 해제하고 배치의 다른 작업을 계속 진행할 수 있습니다.
예: 작업 1과 작업 2는 연속적으로 예약된 두 개의 관리 작업입니다.
작업 1일일 백업
이것은 프로젝트 파티션에서 백업 파티션(예: /mnt/backupProj)으로 많은 수의 파일을 복사합니다. 이 파티션은 즉시 마운트되고 이 작업이 끝나면 마운트 해제됩니다. 복사에는 상당한 시간이 걸립니다.
작업 2SQL 뷰 업데이트
전용 서버에서 일련의 데이터베이스 보기 업데이트를 수행합니다.
작업 2는 분명히 작업 1과 완전히 독립적이므로 백업 작업이 완료될 때까지 기다리지 않고 /mnt/backupProj를 지연 마운트 해제할 수 있습니다.
답변4
다음 작업 시 볼 수 있는 바인드 마운트를 고려해보세요 chroot.
mount --rbind /proc /mnt/proc
# do stuff
umount /mnt/proc
시스템에 지속적으로 질문하는 데몬이 있는 경우 /proc(나는 당신을 보고 있습니다 ksysguardd), 다음을 수행할 수 없습니다 umount /mnt/proc. umount이 경우 게으른 것이 당신을 허락할 것입니다 .