Skip to contentSkip to conversation

mount recovery taking quite long time

DISCUSSION Arkadiusz Miśkiewicz 2 participants 2 messages Feb 15, 2012 – Feb 16, 2012

lore
Share & tools
lore
#0 lore raw

3.0.17 kernel, 800GB fs, fresh boot, mount of /home at boot (so no daemons running yet), and :

[   17.768459] XFS (md3): Starting recovery (logdev: internal)
[  872.427061] XFS (md3): Ending recovery (logdev: internal)

That mount was after (unfortunate) machine reset while it was doing many things.

The question is - what could take so long in here?

Signature · 7 lines
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#1 lore raw
Quoted 11 lines · Arkadiusz Miśkiewicz

3.0.17 kernel, 800GB fs, fresh boot, mount of /home at boot (so no daemons running yet), and :

[   17.768459] XFS (md3): Starting recovery (logdev: internal)
[  872.427061] XFS (md3): Ending recovery (logdev: internal)

That mount was after (unfortunate) machine reset while it was doing many things.

The question is - what could take so long in here?

How big is the log? It's entirely possible that your log is full of modified inodes and so it's having to read them all in first. A modified inode only takes a couple of hundred bytes in the log, so even if you have a 100MB log, you can still have a couple of million dirty inodes in the log that have to be read and replayed.

This has been known for some time, but the worse case (around 15 minutes - what you've seen here - is most I've seen or heard reported) is relatively rare so there hasn't been any urgency to solve this:

http://xfs.org/index.php/Improving_Metadata_Performance_By_Reducing_Journal_Overhead#Reducing_Recovery_Time

Cheers,

Dave.

Signature · 7 lines
Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs