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