All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Steve Brooks <sjb14@st-andrews.ac.uk>, xfs@oss.sgi.com
Subject: Re: Advice needed with file system corruption
Date: Fri, 15 Jul 2016 09:33:27 +1000	[thread overview]
Message-ID: <20160714233327.GT1922@dastard> (raw)
In-Reply-To: <20160714141751.GC16096@redhat.com>

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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-07-14 23:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14 12:27 Advice needed with file system corruption Steve Brooks
2016-07-14 13:05 ` Carlos Maiolino
2016-07-14 13:57   ` Steve Brooks
2016-07-14 14:17     ` Carlos Maiolino
2016-07-14 23:33       ` Dave Chinner [this message]
2016-08-08 14:11 ` Emmanuel Florac
2016-08-08 15:38   ` Roger Willcocks
2016-08-08 15:44     ` Emmanuel Florac
2016-08-09  4:02       ` Gim Leong Chin
2016-08-09 12:40         ` Carlos E. R.
2016-08-09 15:43           ` Gim Leong Chin
2016-08-09 21:26           ` Dave Chinner
2016-08-08 16:16   ` Steve Brooks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160714233327.GT1922@dastard \
    --to=david@fromorbit.com \
    --cc=sjb14@st-andrews.ac.uk \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.