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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
