Skip to contentSkip to conversation

Progress indicator when (slowly) mounting a btrfs filesystem?

DISCUSSION Christian Rohmann 4 participants 5 messages Jan 27, 2016 – Feb 1, 2016 Btrfs file system

lore
Share & tools
lore
#0 lore raw

Hey btrfs-folks,

when one cuts the power to a machine with an 8 device RAID6 btrfs mounted, it takes about 15 - 20 minutes to mount the btrfs again afterwards. This is with kernel 4.4 and btrfs-progs 4.4 mind you. I looked at iotop and it was reading from all disks heavily, so it was doing something. The long mount time for such a rather expected case might be a problem in itself, but either way, a mount action that takes a while needs to present some sort of progress indication, so the user knows what btrfs is at work getting things mounted.

Regards

Christian

#1 lore raw

In my experience there are cases where the system does nothing and it just appears to hang but leaving it overnight results in success.

Very strange indeed.

Quoted 20 lines · Christian Rohmann

Hey btrfs-folks,

when one cuts the power to a machine with an 8 device RAID6 btrfs mounted, it takes about 15 - 20 minutes to mount the btrfs again afterwards. This is with kernel 4.4 and btrfs-progs 4.4 mind you. I looked at iotop and it was reading from all disks heavily, so it was doing something. The long mount time for such a rather expected case might be a problem in itself, but either way, a mount action that takes a while needs to present some sort of progress indication, so the user knows what btrfs is at work getting things mounted.

Regards

Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to Christian Rohmann
Quoted 10 lines · Christian Rohmann

Hey btrfs-folks,

when one cuts the power to a machine with an 8 device RAID6 btrfs mounted, it takes about 15 - 20 minutes to mount the btrfs again afterwards. This is with kernel 4.4 and btrfs-progs 4.4 mind you. I looked at iotop and it was reading from all disks heavily, so it was doing something. The long mount time for such a rather expected case might be a problem in itself, but either way, a mount action that takes a while needs to present some sort of progress indication, so the user knows what btrfs is at work getting things mounted.

Might be a bug, but more likely might be a lack of optimization. If it eventually mounts without errors that's a pretty good plus. Lots of file systems can't handle power failures well at all.

Mount is part of util-linux, not btrfs-progs, so any change would probably need to be there. I'm not sure the kernel even has an idea during all of this what the end point is, so a progress indication is probably not reliable. It's in the clouds on a long staircase, or maybe it's a short one, who can be sure?

Signature · 1 line
Chris Murphy
#3 lore raw

Hey Chris,

Quoted 3 lines · Chris Murphy

Might be a bug, but more likely might be a lack of optimization. If it eventually mounts without errors that's a pretty good plus. Lots of file systems can't handle power failures well at all.

So what and how should I go about profiling such a long running mount in order to help finding point where optimization is needed the most then?

Just as a side note: I don't think it's your own expectation to be like all those other file systems ;-)

Regards

Christian

#4 lore raw
Quoted 9 lines · Christian Rohmann

Hey Chris,

Quoted 3 lines · Chris Murphy

Might be a bug, but more likely might be a lack of optimization. If it eventually mounts without errors that's a pretty good plus. Lots of file systems can't handle power failures well at all.

So what and how should I go about profiling such a long running mount in order to help finding point where optimization is needed the most then?

It would probably require some work with perf and ftrace, which means you likely need to build a special kernel just for testing, and then generate an ideally clean-room like environment (whatever hosting, plus userspace, plus a consistent filesystem image that you can reuse for each test, etc).

Kernel profiling is a decidedly non-trivial task, and is not something I would recommend somebody try unless both:
a) They already have a working knowledge of kernel internals, or are willing to learn.
b) They have the time and resources to do it right in a reproducible manner.