public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: Re: [PATCH 0/5] metadump: discontiguous directory block support
Date: Mon, 3 Feb 2014 14:19:26 +1100	[thread overview]
Message-ID: <20140203031926.GP13997@dastard> (raw)
In-Reply-To: <1390472635-17225-1-git-send-email-david@fromorbit.com>

ping?

On Thu, Jan 23, 2014 at 09:23:50PM +1100, Dave Chinner wrote:
> Hi folks,
> 
> In making xfs_repair handle discontiguous directory blocks properly,
> it uncovered the fact that xfs_metadump has never handled
> discontiguous directory blocks properly. It doesn't handle
> discontiguous block format directories, and there are a couple of
> other cases where it is just says "too hard" and gives up, leading
> to un-obfuscated, corrupt or missing directory blocks in the
> metadump image. xfs/291 on CRC enabled filesystems was causing all
> three of these conditions to occur.
> 
> This patchset fixes metadump to fully support all forms of
> discontiguous directory blocks. It changes the obfuscation code from
> reading and extent at a time and trying to slice and dice the
> objects within it - which will never work for objects that need CRC
> recalculation as a result of obfuscation - to dealing with
> individual objects. This does affect IO patterns somewhat - single
> large contiguous IOs turn into multiple smaller sequential IOs - but
> it means that we can use the object verifiers to do CRC
> recalculation correctly.
> 
> It also means we can walk the extent tree to gather discontiguous
> extents into a single buffer to build an object fom multiple IOs.
> This is what all the other directory block IO does, and we need to
> do it here too.
> 
> The result is that the code is simpler and more obvious in what it
> does - the "walk over a large extent" code is generic rather than
> object specific, and the discontiguous block code is separated from
> the single block object code. Hence both cases are clearer and
> easier to understand.
> 
> And it works, unlike the old code.
> 
> FWIW, with this fixed and xfs/291 passing, the only remaining
> outstanding work that is blocking a 3.2.0 release is to trap IO
> verifier errors in repair so we repair/rebuild objects based on CRC
> errors.
> 
> Comments, flames, thoughts all welcome.
> 
> Cheers,
> 
> Dave.
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

-- 
Dave Chinner
david@fromorbit.com

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

      parent reply	other threads:[~2014-02-03  3:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23 10:23 [PATCH 0/5] metadump: discontiguous directory block support Dave Chinner
2014-01-23 10:23 ` [PATCH 1/5] metadump: sanitise write_buf/index return values Dave Chinner
2014-02-03 11:08   ` Christoph Hellwig
2014-02-13 19:30   ` Mark Tinguely
2014-02-14  2:20     ` Dave Chinner
2014-02-14 19:51       ` Mark Tinguely
2014-02-14 20:54         ` Mark Tinguely
2014-01-23 10:23 ` [PATCH 2/5] metadump: support writing discontiguous io cursors Dave Chinner
2014-02-03 15:06   ` Christoph Hellwig
2014-01-23 10:23 ` [PATCH 3/5] metadump: separate single block objects from multiblock objects Dave Chinner
2014-02-03 15:09   ` Christoph Hellwig
2014-02-03 22:19     ` Dave Chinner
2014-01-23 10:23 ` [PATCH 4/5] metadump: walk single fsb objects a block at a time Dave Chinner
2014-02-03 15:43   ` Christoph Hellwig
2014-01-23 10:23 ` [PATCH 5/5] metadump: fully support discontiguous directory blocks Dave Chinner
2014-02-03 21:15   ` Christoph Hellwig
2014-02-03  3:19 ` 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=20140203031926.GP13997@dastard \
    --to=david@fromorbit.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