public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ben Myers <bpm@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 07/16] xfs: add CRC checks for quota blocks
Date: Wed, 6 Mar 2013 09:49:36 +1100	[thread overview]
Message-ID: <20130305224936.GQ26081@dastard> (raw)
In-Reply-To: <20130305203615.GK22182@sgi.com>

On Tue, Mar 05, 2013 at 02:36:15PM -0600, Ben Myers wrote:
> Hi Dave,
> 
> On Mon, Feb 25, 2013 at 12:31:32PM +1100, Dave Chinner wrote:
> > From: Christoph Hellwig <hch@lst.de>
> > 
> > Use the reserved space in struct xfs_dqblk to store a UUID and a crc
> > for the quota blocks.
> > 
> > [dchinner@redhat.com] Add a LSN field and update for current verifier
> > infrastructure.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> 
> Been over this and it looks fine.
> 
> > @@ -897,6 +910,10 @@ xfs_qm_dqiter_bufs(
> >  		if (error)
> >  			break;
> >  
> > +		/*
> > +		 * XXX(hch): need to figure out if it makes sense to validate
> > +		 *	     the CRC here.
> > +		 */
> 
> What's you're opinion on this?

I did actually change the code to validate the CRC here via
the call to xfs_trans_read_buf(.... &xfs_dquot_buf_ops) above. i.e.
the read verifier will do CRC validation of the buffer.

The comment is still relevant, however, because it's not exactly
clear what the best approach to do here if we get a CRC failure.
That would indicate some kind of corruption that we weren't
expecting, and quite possibly a corruption that rewriting the dquot
can't fix. So without knowing what kind of corruption is typical
here, I don't know what the best approach to take here is.

So effectively what I've done is add CRC validation so that we'll
get people telling us about problems (because the quotacheck will
abort and there will be a stack trace in the log). If it turns out
that corrupted quota files is a common problem that quotacheck
encounters we can gather the corpses, do post-mortem analysis of the
failures and then revisit the code appropriately with that knowledge
in hand.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2013-03-05 22:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-25  1:31 [PATCH 00/16] xfs: metadata CRCs, second batch Dave Chinner
2013-02-25  1:31 ` [PATCH 01/16] xfs: rearrange some code in xfs_bmap for better locality Dave Chinner
2013-02-25 14:44   ` Mark Tinguely
2013-03-07 18:48   ` Ben Myers
2013-02-25  1:31 ` [PATCH 02/16] xfs: take inode version into account in XFS_LITINO Dave Chinner
2013-02-25  1:31 ` [PATCH 03/16] xfs: add support for large btree blocks Dave Chinner
2013-02-25  1:31 ` [PATCH 04/16] xfs: add CRC checks to the AGF Dave Chinner
2013-02-25  1:31 ` [PATCH 05/16] xfs: add CRC checks to the AGFL Dave Chinner
2013-03-01 23:56   ` Ben Myers
2013-02-25  1:31 ` [PATCH 06/16] xfs: add CRC checks to the AGI Dave Chinner
2013-02-25  1:31 ` [PATCH 07/16] xfs: add CRC checks for quota blocks Dave Chinner
2013-03-05 20:36   ` Ben Myers
2013-03-05 22:49     ` Dave Chinner [this message]
2013-02-25  1:31 ` [PATCH 08/16] xfs: add version 3 inode format with CRCs Dave Chinner
2013-02-25  1:31 ` [PATCH 09/16] xfs: add CRC checks to remote symlinks Dave Chinner
2013-02-27 23:35   ` Dave Chinner
2013-02-25  1:31 ` [PATCH 10/16] xfs: add CRC checks to block format directory blocks Dave Chinner
2013-02-25  1:31 ` [PATCH 11/16] xfs: add CRC checking to dir2 free blocks Dave Chinner
2013-02-25  1:31 ` [PATCH 12/16] xfs: add CRC checking to dir2 data blocks Dave Chinner
2013-02-25  1:31 ` [PATCH 13/16] xfs: add CRC checking to dir2 leaf blocks Dave Chinner
2013-02-25  1:31 ` [PATCH 14/16] xfs: add CRCs to dir2/da node blocks Dave Chinner
2013-02-25  1:31 ` [PATCH 15/16] xfs: add CRCs to attr leaf blocks Dave Chinner
2013-02-25  1:31 ` [PATCH 16/16] xfs: add CRC checks to the superblock Dave Chinner

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=20130305224936.GQ26081@dastard \
    --to=david@fromorbit.com \
    --cc=bpm@sgi.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