Score:1

Server

How does a lazy unmount actually work?

KdgDev

9/18/23, 11:55 PM

During recent testing, I couldn't unmount an NFS mount after removing the NFS server or blocking the IP address of the server on PREROUTING raw, with iptables.

--force didn't work. Running mount to print all mounts showed it was still there.

But --lazy did.

Plenty of results to be found telling a person to do this. And that the manpage describes --force in particular for NFS servers that won't hang up.

But what exactly is the algorithm behind --lazy? How does the system know if the device is no longer busy?

It says it's unmounted, but how can I tell if operations are still happening in the background or not?

Last thing I want is a system that claims to be unmounted but is still opening connections that I can't see.

How can I go about verifying the mount is actually gone? Or read up about ways to verify this?

0 + 0

linux

nfs

mount

Score:1

Server

Matthew Ife

9/23/23, 10:30 AM

Laziness is managed by a counter referencing the specific mount_id.

All open file handles that reference the paths being used have to be closed or finished.

When the file tree is detached from the filesystem hierarchy, the counter can only go down. When it reaches 0, the filesystem is properly closed and cleaned up.

It should be noted however, if you mount with the hard mount option and you a performing a read, its possible for an NFS read task to never finish and delay indefinitely, as such some lazy unmounts may never complete.

0 + 0

KdgDev

9/23/23, 8:28 PM

Assuming a soft mount with a custom low amount of retransmits... all connections should receive an I/O error after a few seconds, and then after a few tries, stop retrying and then it's all good, I think?

Matthew Ife

9/24/23, 7:16 AM

@KdgDev thats not so clear. If you have a process with its current working directory inside a NFS mount you're trying to close, unless the process moves out of that directory I dont see how the reference count will get eventually closed.

KdgDev

9/24/23, 11:45 AM

Indeed, that is be the only case I couldn't verify theoretically. However in practice, I know only 1 process uses the mount I'm investigating, and its working directory is elsewhere.

Matthew Ife

9/24/23, 12:23 PM

@KdgDEv you could also have the mount path bind mounted, or have the mount propagated to a private mount namespace. Both of which would lead technically to a partially detached mount point. These are more exceptional circumstances however you'll less likely to encounter in the real world.

Score:0

Server

kofemann

9/23/23, 9:55 AM

Lazy umount is a regular umount, which happens in background. In addition is hides the mount entry, which makes it looks like umount have worked (or Detach the filesystem from the file hierarchy, how man page says). In really the unmount will happen when filesystem is not in use anymore.

Thus, for a real umount one should use --force and wait ...