very long log recovery at mount

[Michael L. Semon]

On 10/21/15 05:27, Arkadiusz Miśkiewicz wrote:
>
> Hi.
>
> I got such situation, fresh boot, 4.1.10 kernel, init scripts start mounting
> filesystems. One fs wasn't very lucky:
>
> [   15.979538] XFS (md3): Mounting V4 Filesystem
> [   16.256316] XFS (md3): Ending clean mount
> [   28.343346] XFS (md4): Mounting V4 Filesystem
> [   28.629918] XFS (md4): Ending clean mount
> [   28.662125] XFS (md5): Mounting V4 Filesystem
> [   28.980142] XFS (md5): Ending clean mount
> [   29.049421] XFS (md6): Mounting V4 Filesystem
> [   29.447725] XFS (md6): Starting recovery (logdev: internal)
> [ 4517.327332] XFS (md6): Ending recovery (logdev: internal)
>
> It took over 1h to mount md6 filesystem.
>
> Questions:
> - is it possible to log how much data is needed to be recovered from log? Some
> data that would give a hint on how big this is (and thus rough estimate on how
> long it will take). Not sure if that's known at time when this message is
> being printed.
>
> XFS (md6): Starting recovery (logdev: internal, to recover: xyzMB (?))
>
> - now such long mount time is almost insane, so I wonder why could be the
> reason. Is the process multithreaded, single threaded? cpus were idle
>

My old PC used to suffer from intermittently long mount times, and I wrote a
one-character patch to fix that issue:

http://oss.sgi.com/archives/xfs/2015-01/msg00183.html

I'm putting it out there only to ask the list if wrapped-log handling could be
the issue here.  Don't try the patch without good reason:  I've tested it only
as late as kernel 3.18.22, on 32-bit Linux with MBR and GPT partitions, not
much of a test matrix.

Thanks!

Michael