Closed Forza-tng closed 7 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?
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.
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.
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.
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)
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.
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?
Nope, this won't work as inotify doesn't work on sysfs at all...
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.
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.
Bonus points if there is a way to see what holders remain on the filesystem. Something like
btrfs filesystem mount --report /dev/device