From: Dave Chinner <david@fromorbit.com>
To: Peter Watkins <treestem@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_repair: enabling lazy sb counters
Date: Wed, 26 Sep 2012 07:24:42 +1000 [thread overview]
Message-ID: <20120925212442.GE29154@dastard> (raw)
In-Reply-To: <CAH4wwdG4j_53UYUtU-h3uwaqMOwDz+EsvXLojWKgCx5i7Ftndw@mail.gmail.com>
On Tue, Sep 25, 2012 at 11:40:33AM -0400, Peter Watkins wrote:
> Hello,
>
> Has anyone noticed that phase1 updates the lazy count flag in the
> superblock, and then writes out the sb before the traversal in phase5
> counts btree blocks consumed and sets agf_btreeblks?
Not until now. :/
> Seems like if xfs_repair is interrupted or crashes at the wrong time,
> you'd have enabled lazy count but not set agf_btreeblks, which would
> trigger the corruption check in xfs_alloc.c:xfs_read_agf().
Which tells you to run xfs_repair, right?
> If you just re-run xfs_repair to enable lazy counts, it would stop
> early saying they're already enabled. You'd have to disable them, and
> then enable again to get a consistent state.
Or you just run xfs_repair without trying to change the lazy count
state - that will recalculate the btreeblks count as part of the
normal repair process....
> Second, is it possible to enable lazy counts without doing the
> full repair traversal, i.e. a cheap and easy way to set
> agf_btreeblks if the fs is already consistent? On some systems,
> the whole repair enchilada can take a long time!
The current process is that xfs_repair -rebuilds- the freespace
trees from it's in memory state, and it takes until phase 5 for
xfs_repair to have a full picture of the freespace in the filesystem
after fixing up possible errors.
So basically when you enable lazy counters, repair essentially
verifies all the freespace is correct before enabling it. That's a
necessary pre-requisite for lazy-counters to work correctly, and the
only way to ensure it is to walk the filesystem first.
That said, if you really want to avoid running a full xfs_repair,
you can always count the btree blocks manually with xfs_db and set
the btreeblk count fields yourself. You get to keep the broken
pieces when something goes wrong, though. :/
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2012-09-25 21:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-25 15:40 xfs_repair: enabling lazy sb counters Peter Watkins
2012-09-25 21:24 ` Dave Chinner [this message]
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=20120925212442.GE29154@dastard \
--to=david@fromorbit.com \
--cc=treestem@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox