Advice needed with file system corruption

[Dave Chinner]

On Thu, Jul 14, 2016 at 04:17:51PM +0200, Carlos Maiolino wrote:
> On Thu, Jul 14, 2016 at 02:57:25PM +0100, Steve Brooks wrote:
> > Hi Carlos,
> > 
> > Many thanks again, for your good advice. I ran the version 4.3 of
> > "xfs_repair" as suggested below and it did it's job very quickly in 50
> > seconds exactly as reported in the "No modify mode". Is the time reported at
> > the end of the "No modify mode" always a good approximation of running in
> > "modify mode" ?
> 
> Good to know. But I'm not quite sure if the no modify mode could be used as a
> good approximation of a real run. I would say to not take it as true giving that
> xfs_repair can't predict the amount of time it will need to write all
> modifications it needs to do on the filesystem's metadata, and it will certainly
> can take much more time, depending on how corrupted the filesystem is.

Yup, the no-modify mode skips a couple of steps in repair - phase 5
which rebuilds freespace btrees, and phase 7 which correctly link
counts - and so can only be considered the minimum runtime in "fix
it all up" mode. FWIW, Phase 6 can also blow out massively in
runtime if there's significant directory damage that results in
needing to move lots of inodes to the lost+found directory.

> > > Hi steve.
> > > 
> > > On Thu, Jul 14, 2016 at 01:27:22PM +0100, Steve Brooks wrote:
> > > > The "3.1.1"  version of "xfs_repair -n" ran in 1 minute, 32 seconds
> > > > 
> > > > The "4.3"     version of "xfs_repair -n" ran in 50 seconds

And it's good to know that recent performance improvements show real
world benefits, not just on the badly broken filesystems I used for
testing.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com