3 ms·

I recently discovered that Linux handles processes holding files open a little differently from FreeBSD, too, when I tried to unmount a ZFS volume. Something ha

I recently discovered that Linux handles processes holding files open a little differently from FreeBSD, too, when I tried to unmount a ZFS volume. Something had ahold of a file on it, so I couldn't unmount it—on FreeBSD you can just say "I want all programs that are preventing this to fuck off and, if they're so inclined, to crash"—and ZFS provides a flag to do just that—and go on with your day, but Linux evidently won't let you (I ended up on some ZFS mailing list archive to confirm this was the case and I wasn't just holding it wrong). You have to go track the process(es) down and kill it(/them) yourself, not unlike how you can't delete a file that's in use on Windows and have to go kill the processes. It was faster to just reboot the damn machine than to do that (a very Windows solution). [EDIT] It may have been a ZFS export operation, not exactly an unmount? I can't recall for sure. Point is, Linux made you go find and kill the relevant processes yourself, while FreeBSD made it trivial to override that and do what you needed to do with no further fuss.

yencabulator 4y ago
Back in the day there was a patch floating around that let you mark mounts as "bad", and all open files would be shunted to a "badfs" which gave I/O errors for all operations. Most of the discussion around it has linkrotted. https://lwn.net/Articles/192632/ https://lwn.net/Articles/192632/ has some mentions. Some filesystems implement a less-comprehensive variant that's `umount(2)` with `MNT_FORCE` -- but generally that's only network/FUSE-style ones: MNT_FORCE (since Linux 2.1.116) Ask the filesystem to abort pending requests before attempting the unmount. This may allow the unmount to complete without waiting for an inaccessible server, but could cause data loss. If, after aborting requests, some processes still have active references to the filesystem, the unmount will still fail. As at Linux 4.12, MNT_FORCE is supported only on the following filesystems: 9p (since Linux 2.6.16), ceph (since Linux 2.6.34), cifs (since Linux 2.6.12), fuse (since Linux 2.6.16), lustre (since Linux 3.11), and NFS (since Linux 2.1.116).

yencabulator 4y ago

Back in the day there was a patch floating around that let you mark mounts as "bad", and all open files would be shunted to a "badfs" which gave I/O errors for all operations. Most of the discussion around it has linkrotted. https://lwn.net/Articles/192632/ https://lwn.net/Articles/192632/ has some mentions. Some filesystems implement a less-comprehensive variant that's `umount(2)` with `MNT_FORCE` -- but generally that's only network/FUSE-style ones: MNT_FORCE (since Linux 2.1.116) Ask the filesystem to abort pending requests before attempting the unmount. This may allow the unmount to complete without waiting for an inaccessible server, but could cause data loss. If, after aborting requests, some processes still have active references to the filesystem, the unmount will still fail. As at Linux 4.12, MNT_FORCE is supported only on the following filesystems: 9p (since Linux 2.6.16), ceph (since Linux 2.6.34), cifs (since Linux 2.6.12), fuse (since Linux 2.6.16), lustre (since Linux 3.11), and NFS (since Linux 2.1.116).