feature request, explicit mount and unmount kernel messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

So XFS has these

[49621.415203] XFS (loop0): Mounting V5 Filesystem
[49621.444458] XFS (loop0): Ending clean mount
...
[49621.444458] XFS (loop0): Ending clean mount
[49641.459463] XFS (loop0): Unmounting Filesystem

It seems to me linguistically those last two should be reversed, but whatever.

The Btrfs mount equivalent messages are:
[49896.176646] BTRFS: device fsid f7972e8c-b58a-4b95-9f03-1a08bbcb62a7
devid 1 transid 5 /dev/loop0
[49901.739591] BTRFS info (device loop0): disk space caching is enabled
[49901.739595] BTRFS info (device loop0): has skinny extents
[49901.767447] BTRFS info (device loop0): enabling ssd optimizations
[49901.767851] BTRFS info (device loop0): checking UUID tree

So is it true that for sure there is nothing happening after the UUID
tree is checked, that the file system is definitely mounted at this
point? And always it's the UUID tree being checked that's the last
thing that happens? Or is it actually already mounted just prior to
disk space caching enabled message, and the subsequent messages are
not at all related to the mount process? See? I can't tell.

For umount, zero messages at all.

The feature request is something like what XFS does, so that we know
exactly when the file system is mounted and unmounted as far as Btrfs
code is concerned.

I don't know that it needs the start and end of the mount and
unmounted (i.e. two messages). I'm mainly interested in having a
notification for "mount completed successfully" and "unmount completed
successfully". i.e. the end of each process, not the start of each.

In particular the unmount notice is somewhat important because as far
as I know there's no Btrfs dirty flag from which to infer whether it
was really unmounted cleanly. But I'm also not sure what the insertion
point for these messages would be. Looking at the mount code in
particular, it's a little complicated. And maybe with some of the
sanity checking and debug options it could get more complicated, and
wouldn't want to conflict with that - or any multiple device use case
either.


-- 
Chris Murphy



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux