UFS Long-term problem: unable to end a umount process .

[MG]

Having this once in a few years, now in FreeBSD 14 amd64 GENERIC: an umount command doesn't finish unmounting and keeps existing in frozen state, resulting in a system that can't do a clean reboot because of this active process.
This means in this case, for a development system. that I have to do a systematic manual take-down of everything else unrelated and do a hard shutdown, hoping that various ZFS pools and other mounts don't get any consistency problems.

This shouldn't be possible. I was working on the content of a md-image and ready to unload it, which I did before without problems. I don't care if all of that gets lost and I have to do it again, but that's no given option. The existing umount process that can't be killed, nor made to show what's going on blocks everything.
Is there any way to prevent this?

 

[tingo]

Have you checked (for example with fstat(1)) which process / processes hold locks on that filesystem?

 

[mer]

I think on UFS there is a syncer process that runs periodically, not sure of the interval but 5 or 30 secs sounds familiar. That may be keeping something open.
Is the umount happening as part of a reboot/shutdown -r command or an explict umount?
Is there a filesystem that may be automounted? I've seen things in the past where automounting mucked up my understanding of what is mounted and what is not. Some graphical file managers automount all the things.

 

[Erichans]

hoping that various ZFS pools and other mounts don't get any consistency problems

You haven't mentioned if your OS is ZFS on root or UFS is the root fs. If you didn't make "fancy" ZFS changes (like disabling ZFS sync where you shouldn't have) pools are usually unexpectantly resilent against power failures and hard resets.
That said, for any pool that is not part of the root filesystem, you should be able to use zpool-export(8). Using that should unmount all fs-s (data sets) of that pool. Using zpool-export(8) won't help your UFS umount problem of course, but you'll have taken every ZFS precaution possible.

I think on UFS there is a syncer process that runs periodically

It couldn't hurt to issue a couple of sync(8) manually if you haven't tried, I know that shouldn't be necessary.

 

[Cath O'Deray]

I can't imagine sync helping in this situation, but it'll do no harm.

… once in a few years, now

For so infrequent an issue, I might suspect hardware.

When umount runs endlessly: does lsof run to completion for the affected volume?

in FreeBSD 14 amd64 GENERIC: …

Which version of FreeBSD, exactly?

freebsd--version -kru ; uname -aKU

 

[cracauer@]

It is not a process holding a file open or locked inside the filesystem. That would make the umount system call fail, not hang.

This is a kernel-internal problem, presumably waiting on some hardware interface in a context with no timeout.

Please describe the hardware making up the storage subsystem leading to the filesystem in question. And what filesystem and other layers (encryption etc) does it have?

 

[Andriy]

procstat -kk <pid-of-umount-process> would give the most info at this stage.

 

[SirDice]

I'd check the disks themselves with smartctl(8) too. A drive may have a bunch of read/write errors, constant retries may be preventing a clean unmount.

 

[skunk]

A drive may have a bunch of read/write errors, constant retries may be preventing a clean unmount.

Long ago I have read that this constant retrying is typical for consumer grade drives, and enterprise drives instead error out rather quickly to avoid just this problem that the OP describes. No idea whether this is true.
But, I can confirm from my experience that there are/were bad hard disks that literally could retry for hours until giving up, and all of these were no enterprise grade.