From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: Re: [PATCH 00/22 V4] xfs: metadata verifiers
Date: Wed, 7 Nov 2012 17:05:45 +1100 [thread overview]
Message-ID: <20121107060545.GC6434@dastard> (raw)
In-Reply-To: <20121106210444.GE24575@dastard>
On Wed, Nov 07, 2012 at 08:04:44AM +1100, Dave Chinner wrote:
> On Tue, Nov 06, 2012 at 04:13:11PM +1100, Dave Chinner wrote:
> > Hi folks,
> >
> > Fourth version of the buffer verifier series. The read verifier
> > infrastructure is described here:
> >
> > http://oss.sgi.com/archives/xfs/2012-10/msg00146.html
> >
> > The second version with write verifiers is described here:
> >
> > http://oss.sgi.com/archives/xfs/2012-10/msg00280.html
> >
> > This version add write verifiers to all buffers that aren't directly
> > read (i.e. via xfs_buf_get*() interfaces), and drops the log
> > recovery verifiers from the series as it really needs more buffer
> > item format flags to do relaibly.
> >
> > The seris is just about ready to go - it passes all of xfstests here
> > except for 070. With the addition of the getbuf write verifiers,
> > this series is now detecting a corrupt xfs_da_node buffer being
> > written to disk. It appears to be a new symptom of known problem,
> > as tracing indicates that the test is triggering the same double
> > split/join pattern as described here:
> >
> > http://oss.sgi.com/archives/xfs/2012-03/msg00347.html
>
> So, 070 isn't hitting this exact problem - I think i have a handle
> on the cause of the problem in the link now (i.e. I have a fix that
> passes all of xfstests without any other problems arising), but the
> reproducer is also causing the same write verifier failures as 070
> and 117. However, all three do a double leaf split operation, so
> that's going to be the underlying cause of the verifier failure.
They underlying cause is the fact that leaf format attribute tree
format is unreliable when there are remote attributes. The detection
is based on the being precisely one block at offset 0 in the
attribute fork bmap btree, and when you add remote attributes that
is no longer true, even though the root block of the attribute tree
is still a leaf.
Hence there is code in the node format detection that specifically
handles leaf format trees when doing node format operations. This is
how the xfs_da_node_buf_ops get attached to attribute leaf format
buffers being read from disk - they pass verification because the
da node format verifier sees the leaf magic number and calls the
appropriate verifier instead.
This issue was that the original code I wrote had the read verifier
set the write verifier, so this act of calling the correct read
verifier also set the write verifier correctly. Convert to an ops
structure meant that this implicit rewrite of the write verifier no
longer occurred, and boomy-boom-boom when the write verifier when
the above situation occurs.
I just posted a V2 patch for 22/22 that fixes this. Now all xfstests
pass with the patch set.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-11-07 6:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 5:13 [PATCH 00/22 V4] xfs: metadata verifiers Dave Chinner
2012-11-06 5:13 ` [PATCH 01/22] xfs: make buffer read verication an IO completion function Dave Chinner
2012-11-06 5:13 ` [PATCH 02/22] xfs: uncached buffer reads need to return an error Dave Chinner
2012-11-06 5:13 ` [PATCH 03/22] xfs: verify superblocks as they are read from disk Dave Chinner
2012-11-06 5:13 ` [PATCH 04/22] xfs: verify AGF blocks " Dave Chinner
2012-11-06 5:13 ` [PATCH 05/22] xfs: verify AGI " Dave Chinner
2012-11-06 5:13 ` [PATCH 06/22] xfs: verify AGFL " Dave Chinner
2012-11-06 5:13 ` [PATCH 07/22] xfs: verify inode buffers " Dave Chinner
2012-11-06 5:13 ` [PATCH 08/22] xfs: verify btree blocks " Dave Chinner
2012-11-06 5:13 ` [PATCH 09/22] xfs: verify dquot " Dave Chinner
2012-11-06 5:13 ` [PATCH 10/22] xfs: add verifier callback to directory read code Dave Chinner
2012-11-06 5:13 ` [PATCH 11/22] xfs: factor dir2 block read operations Dave Chinner
2012-11-06 5:13 ` [PATCH 12/22] xfs: verify dir2 block format buffers Dave Chinner
2012-11-06 5:13 ` [PATCH 13/22] xfs: factor dir2 free block reading Dave Chinner
2012-11-06 5:13 ` [PATCH 14/22] xfs: factor out dir2 data " Dave Chinner
2012-11-06 5:13 ` [PATCH 15/22] xfs: factor dir2 leaf read Dave Chinner
2012-11-06 5:13 ` [PATCH 16/22] xfs: factor and verify attr leaf reads Dave Chinner
2012-11-06 5:13 ` [PATCH 17/22] xfs: add xfs_da_node verification Dave Chinner
2012-11-06 5:13 ` [PATCH 18/22] xfs: Add verifiers to dir2 data readahead Dave Chinner
2012-11-06 5:13 ` [PATCH 19/22] xfs: add buffer pre-write callback Dave Chinner
2012-11-06 5:13 ` [PATCH 20/22] xfs: add pre-write metadata buffer verifier callbacks Dave Chinner
2012-11-06 5:13 ` [PATCH 21/22] xfs: connect up write verifiers to new buffers Dave Chinner
2012-11-06 5:13 ` [PATCH 22/22] xfs: convert buffer verifiers to an ops structure Dave Chinner
2012-11-07 5:58 ` [PATCH 22/22 V2] " Dave Chinner
2012-11-06 21:04 ` [PATCH 00/22 V4] xfs: metadata verifiers Dave Chinner
2012-11-07 6:05 ` Dave Chinner [this message]
2012-11-07 13:17 ` [PATCH 23/22] xfs: buffer type changes in xfs_da_root_join 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=20121107060545.GC6434@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