kdave / btrfs-progs

Development of userspace BTRFS tools
GNU General Public License v2.0
527 stars 239 forks source link

Enhancement: Write to dmesg when fs is unmounted #689

Closed Forza-tng closed 7 months ago

Forza-tng commented 9 months ago

It would be good if btrfs would write out a notice in dmesg when the last mount point to the filesystem is unmounted.

Btrfs supports multiple mount points to the same filesystem, which is a great feature. However, if can be difficult to know when a filesystem is truly unmounted. Sometimes a mount might be in a namespace or for other reasons do not show up in df, which could cause issues if you need to remove the device or do some low level operation.

A simple dmesg info notice would avoid confusion.

BTRFS info (device dm-18): unmounted

Bonus points if there is a way to see what holders remain on the filesystem. Something like btrfs filesystem mount --report /dev/device

kdave commented 9 months ago

Bonus points if there is a way to see what holders remain on the filesystem. Something like btrfs filesystem mount --report /dev/device

So this would be some pretty-printer for cat /proc/self/mounts | grep /dev/device ? What should be printed?

kdave commented 9 months ago

Regarding the mount logging, there were patches for that but I was against as this IMO belong to a different layer, like audit o some generic VFS event logger. Any filesystem could be monitored like that without adding own printk.

While I understand that it's easy to simply scan the log and grep for the messages (assuming printed by btrfs) it's kind of a thing that is not popular to add filesystem-specific code when there should be something more generic. I don't know if inotify/fsnotify supports that.

Zygo commented 9 months ago

So this would be some pretty-printer for cat /proc/self/mounts | grep /dev/device

Doesn't work after the filesystem has been lazy-umounted, or if it remains mounted in some other mount namespace. Some process might be holding an open fd, or use the filesystem as its root or executable, and keep the filesystem mounted in the kernel with no mount points at all.

If you know the uuid, check /sys/fs/btrfs/$uuid, which sticks around until the last fd on the mounted filesystem is closed.

Forza-tng commented 9 months ago

I've had troubles with both lazy unmount and namespaces in the past, which is why I thought about this request.

However, I think Zygo makes a good point to look in /sys/fs/btrfs for the uuid, which is satisfactory for me. Mind that maybe many users never know to look there.

adam900710 commented 8 months ago

I believe the unmount dmesg would be pretty good and useful. IIRC Xfs is already outputting such message.

Another thing related to the idea of using other tools like epbf is, there is no easy document just to do it simply. If an end user just want to know if and when a btrfs got unmounted, pointing them to some rabbit hole of ebpf is definitely not user friendly.

Considering the extremely low cost, I really recommend to add unmount dmesg from btrfs. (Or we need to add a doc showing how to do that using some other tool at least)

kdave commented 8 months ago

Ok, let's do it, the use cases are clear. As said in the patch discussion, we can add a command that would wait for umount watching the sysfs file, like btrfs filesystem wait-for-umount where the argument is anything that can identify the filesystem, UUID, device node path (/dev/sdx) or any path to in the filesystem.

adam900710 commented 8 months ago

I'd say we should put all the monitoring related things into btrfs monitor group instead.

For the first step, I'd like to just implement the btrfs monitor watch to watch for the sysfs interface to implement the same mount/unmount monitoring.

In the future we can add wait-unmount <uuid/device> option to wait for certain fs to be unmounted etc. (And maybe wait-mount <uuid/device> for waiting for a certain fs to be mounted)

Would this sound a good plan?

adam900710 commented 8 months ago

Nope, this won't work as inotify doesn't work on sysfs at all...

kdave commented 7 months ago

I did not mean to use inotify but polling the directory. The dentries are all cached so this is quick.

The patch adding the first mount/last unmount are now in 6.8 queue, closing.