26

I have read that it is possible to 'umount' a disk that is otherwise busy by using the 'lazy' option. The manpage has this to say about it:

umount - unmount file systems

-l Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore. This option allows a "busy" filesystem to be unmounted. (Requires kernel 2.4.11 or later.)

But what would be the point in that? I considered why we dismount partitions at all:

  1. To remove the hardware
  2. To perform operations on the filesystem that would be unsafe to do while mounted

In either of these cases, all a 'lazy' unmount serves IMHO is to make it more difficult to determine if the disk really is dismounted and you can actually proceed with these actions. The only application for umount -l seems to be for inexperienced users to 'feel' like they've achieved something they haven't.

Why would you use a lazy unmount?

Improve this question

7 Answers 7

Reset to default
6

Say you really need to change the volume on which a software is writing a log, e.g. a web server, but it has a lot of traffic and can't be turned off for the operation nor can the logging path be changed.

With lazy unmount, you can safely unmount the volume while the software is still running, mount another volume on to that same mountpoint and command the software to reopen files.

Ideally, since you didn't need to turn off the software, no requests were lost and essentially no log entries were lost either, since they were still being written to the old mount until the files were reopened (how well the software handles reopening the files is up to the software).

Paraphrasing the manpage, it means that if the volume has open files when it is lazy unmounted, in reality it remains mounted but just not accessible through the filesystem and is only truly unmounted when the last open file is closed.

Improve this answer
1
  • 1
    Thanks this sounds like a useful application. Will lsof show open files on the old mountpoint? Also I wonder how would it differentiate open files on the old volume and the new one?
    – deed02392
    May 12, 2018 at 19:02
15

Because you're lazy - you want to unmount after the disk operations are done.

Here's a plausible scenario:

You're using rsync to perform your backups and walk away. You can umount -l the drive and once it's finished copying and synched, it unmounts, so that when you come back after a break (that you know will take longer than the backup) you can just unplug the drive instead of having to fiddle with the keyboard again.

Improve this answer
3
  • If you were lazy, surely you would want to save MORE time by not having to use the argument, because once you got back you knew you could dismount it immediately now the backup has finished? Or make dismounting the drive part of the post-backup operations?
    – deed02392
    Apr 13, 2012 at 15:10
  • Think of it this way: the disk is no longer busy - unmount it now. It's no longer mounted so nothing else can write to it. It's "do this when you can" instead of erroring out.
    – Broam
    Apr 13, 2012 at 19:07
  • So how do you know when the disk operations are done? See this example (bug?) of being able to write a file to an already unmounted filesystem
    – Tom Hale
    Aug 11, 2017 at 9:41
6

This is actually implemented to gain more time to do follow-up tasks in administrative tasks.

If further tasks, independent of this one is waiting in the pipeline, then you can lazy-unmount and go on with others in the batch.

Example: Task 1 and Task 2 are two administrative tasks scheduled back to back.

Task 1 Daily backup

This one copies a large number of files from a project partition to a backup partition, say, /mnt/backupProj, which will be mounted on the fly and unmounted at the end of this task.. The copying takes a significant amount of time.

Task 2 Update SQL-views

Performs a series of database view updates on a dedicated server.

Task 2 is obviously completely independent of Task 1, so we can lazy-unmount /mnt/backupProj without waiting for the backup task to complete.

Improve this answer
1
  • 1
    Can you provide an example? In what situation would it 'gain/save time'?
    – deed02392
    Apr 13, 2012 at 16:30
5

I use lazy umount in cases where it was obviously stuck for various reasons (such as nfs server down), also when I need to see the original content of the directory that was mounted over by the mount. In both cases the mount is busy. I think there are other edge cases but these 2 are the most common reasons I used the option.

Improve this answer
1
  • The recommends --force for the NFS case.
    – Tom Hale
    Aug 11, 2017 at 9:39
3

Consider a bind mount as you might see when working with chroot:

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

If you have a daemon on your system that constantly interrogates /proc (I'm looking at you ksysguardd), then you will be unable umount /mnt/proc. Lazy will let you umount in this case.

Improve this answer
1
  • Why not use --force here instead?
    – Tom Hale
    Aug 11, 2017 at 9:39
2

USB-drives sometimes get stalled because of hardware failure. Even if you reconnect the drive physically, you get another device-name. The old device-name cannot be unmounted normally. amount -l forced the dead entry to vanish.

Improve this answer
1

I use encfs to encrypt part of my sensitive data.

When the disk is mounted, nautilus build up previews (I think, I am not sure), and lock the files. When I want to unmount it, it says that it is locked by another process.

By lazy unmounting it, the folder dissapear from my hierarchy, and is hidden. And when the background process end, it is successfully unmounted.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .