"umount -l" and *BSD

[Rob Browning]

Does umount on the BSDs accept the -l argument?

-l, --lazy

Lazy unmount. Detach the filesystem from the file
hierarchy now, and clean up all references to this
filesystem as soon as it is not busy anymore. (Requires
kernel 2.4.11 or later.)

We're already using it in cleanup-mounts-under, which I noticed after
realizing that -l might be a preferable way to address this suggested
change:

https://github.com/bup/bup/pull/12

So I thought I'd check to see whether that might need to be predicated
on the platform.

Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Greg Troxel]

Rob Browning <r...@defaultvalue.org> writes:

> Does umount on the BSDs accept the -l argument?
>
> -l, --lazy
>
> Lazy unmount. Detach the filesystem from the file
> hierarchy now, and clean up all references to this
> filesystem as soon as it is not busy anymore. (Requires
> kernel 2.4.11 or later.)

No. At least on NetBSD, 5 and 7 both do not list it.

There is -f, which unmounts even if there are open files.

I cannot follow what -l is supposed to mean.

> We're already using it in cleanup-mounts-under, which I noticed after
> realizing that -l might be a preferable way to address this suggested
> change:
>
> https://github.com/bup/bup/pull/12
>
> So I thought I'd check to see whether that might need to be predicated
> on the platform.

I think the big question is if the usage of umount needs to succeed if
there are open files in the mounted filesystem. If not, then -l vs
nothing shouldn't really matter. If so, you need -f. So I think I am
missing something.

While things can be conditionalized per OS (this seems Linux only as it
refers to a kernel version as if no other operating systemx even exist),
I think it's better to avoid such per-OS case statements unless there's
a really compelling reason.

[Rob Browning]

Greg Troxel <g...@lexort.com> writes:

> I cannot follow what -l is supposed to mean.

I'm not positive, but I suspect it may be like the semantics for rm,
i.e. you can rm a file, but if a process has it open, it can finish
using it (via the file descriptor) without errors.

On other platforms, that'll just crash the program, iirc.

> I think the big question is if the usage of umount needs to succeed if
> there are open files in the mounted filesystem. If not, then -l vs
> nothing shouldn't really matter. If so, you need -f. So I think I am
> missing something.

Hmm, it may be that -f will work fine for our purposes, instead of -l.

[Nix]

On 22 Nov 2016, Rob Browning verbalised:

> Greg Troxel <g...@lexort.com> writes:
>
>> I cannot follow what -l is supposed to mean.
>
> I'm not positive, but I suspect it may be like the semantics for rm,
> i.e. you can rm a file, but if a process has it open, it can finish
> using it (via the file descriptor) without errors.

More or less. It detaches the mount point from its parent: it is GCed
(and, if no mounts remain, the filesystem's unmount code called) once
all references to it (open files, cwds, mappings) are discarded.

It's utterly dependent on the mount namespace/propagation code Al Viro
implemented starting in the early 2000s: the design for this derives
largely from Plan 9, not from Unix, so it's not surprising that other
Unixes don't have anything like it.

> On other platforms, that'll just crash the program, iirc.

Non-lazy umount of filesystems that are in use is generally prohibited
on modern Unixes.

--
NULL && (void)

[Greg Troxel]

[dropping Abdel because meapix.com is NXDOMAIN]

Rob Browning <r...@defaultvalue.org> writes:

> Greg Troxel <g...@lexort.com> writes:
>
>> I cannot follow what -l is supposed to mean.
>
> I'm not positive, but I suspect it may be like the semantics for rm,
> i.e. you can rm a file, but if a process has it open, it can finish
> using it (via the file descriptor) without errors.

That certainly sounds like sensible semantics, but I don't see that it's
all that useful, because in my experience when plain umount fails (due
to an open vnode), usually it's because of some long-running paused
program or a shell with a CWD in the fs, and none of those tend to
resolve over the next 10 seconds.

> On other platforms, that'll just crash the program, iirc.

If you mean -f, that revokes all open file descriptors in the
being-unmounted fs, so that any further operations on them get some
errno result. Whether that's a crash depends :-)

>> I think the big question is if the usage of umount needs to succeed if
>> there are open files in the mounted filesystem. If not, then -l vs
>> nothing shouldn't really matter. If so, you need -f. So I think I am
>> missing something.
>
> Hmm, it may be that -f will work fine for our purposes, instead of -l.

In this case, what file descriptors are open in the wanted-to-unmount
fs? Why can't the tests just stop using them before the unmount? Then,
use -f anyway, so that if some helpful volume manager opens the root
vnode to do a statvfs to show something, and doesn't close it, the tests
won't hang, without having to fix that buggy volume manager. (I used to
see this with xfce.)

[Rob Browning]

Greg Troxel <g...@lexort.com> writes:

> In this case, what file descriptors are open in the wanted-to-unmount
> fs? Why can't the tests just stop using them before the unmount? Then,
> use -f anyway, so that if some helpful volume manager opens the root
> vnode to do a statvfs to show something, and doesn't close it, the tests
> won't hang, without having to fix that buggy volume manager. (I used to
> see this with xfce.)

I suppose that's the real question, and it's hard to see what could be
causing the umount error. I'm not sure exactly what version was
involved in the original failure, but I don't think that code's changed
much:

WVPASS cd "$tmpdir"

WVPASS dd if=/dev/zero of=testfs.img bs=1M count=32
WVPASS mke2fs -F -j -m 0 testfs.img
WVPASS mount -o loop testfs.img "$tmpmnt1"
# Hide, so that tests can't create risks.
WVPASS chown root:root "$tmpmnt1"
WVPASS chmod 0700 "$tmpmnt1"

# Create trivial content.
WVPASS date > "$tmpmnt1/foo"
WVPASS umount "$tmpmnt1"

[Greg Troxel]

Rob Browning <r...@defaultvalue.org> writes:

> I suppose that's the real question, and it's hard to see what could be
> causing the umount error. I'm not sure exactly what version was
> involved in the original failure, but I don't think that code's changed
> much:
>
> WVPASS cd "$tmpdir"
>
> WVPASS dd if=/dev/zero of=testfs.img bs=1M count=32
> WVPASS mke2fs -F -j -m 0 testfs.img
> WVPASS mount -o loop testfs.img "$tmpmnt1"

None of that is portable anyway. mke2fs and mount -o loop seem
Linux-only.

[Rob Browning]

Greg Troxel <g...@lexort.com> writes:

> None of that is portable anyway. mke2fs and mount -o loop seem
> Linux-only.

Oh, of course - I'd originally checked to see our existing umount -l was
Linux specific, but didn't check carefully enough, i.e. it's guarded by
a test for /proc/mounts.

Regarding the original problem then, I suppose -l or -f might eliminate
the symptom, but we still wouldn't know why the filesystem was busy.

Thanks