All of lore.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 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.