Progress indicator when (slowly) mounting a btrfs filesystem?

Progress indicator when (slowly) mounting a btrfs filesystem?

[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

Re: Progress indicator when (slowly) mounting a btrfs filesystem?

[bbrendon]

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.

On Wed, Jan 27, 2016 at 8:24 AM, Christian Rohmann
<crohmann@netcologne.de> wrote:
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Progress indicator when (slowly) mounting a btrfs filesystem?

[Chris Murphy]

On Wed, Jan 27, 2016 at 9:24 AM, Christian Rohmann
<crohmann@netcologne.de> wrote:
> 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?


-- 
Chris Murphy

Re: Progress indicator when (slowly) mounting a btrfs filesystem?

[Christian Rohmann]

Hey Chris,

On 01/28/2016 12:47 AM, Chris Murphy wrote:
> 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

Re: Progress indicator when (slowly) mounting a btrfs filesystem?

[Austin S. Hemmelgarn]

On 2016-02-01 09:03, Christian Rohmann wrote:
> Hey Chris,
>
> On 01/28/2016 12:47 AM, Chris Murphy wrote:
>> 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.