All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 5/5] xfs: log recovery lsn ordering needs uuid check
Date: Tue, 24 Sep 2013 12:14:46 -0500	[thread overview]
Message-ID: <20130924171446.GG1935@sgi.com> (raw)
In-Reply-To: <1380002476-18839-6-git-send-email-david@fromorbit.com>

On Tue, Sep 24, 2013 at 04:01:16PM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> After a fair number of xfstests runs, xfs/182 started to fail
> regularly with a corrupted directory - a directory read verifier was
> failing after recovery because it found a block with a XARM magic
> number (remote attribute block) rather than a directory data block.
> 
> The first time I saw this repeated failure I did /something/ and the
> problem went away, so I was never able to find the underlying
> problem. Test xfs/182 failed again today, and I found the root
> cause before I did /something else/ that made it go away.
> 
> Tracing indicated that the block in question was being correctly
> logged, the log was being flushed by sync, but the buffer was not
> being written back before the shutdown occurred. Tracing also
> indicated that log recovery was also reading the block, but then
> never writing it before log recovery invalidated the cache,
> indicating that it was not modified by log recovery.
> 
> More detailed analysis of the corpse indicated that the filesystem
> had a uuid of "a4131074-1872-4cac-9323-2229adbcb886" but the XARM
> block had a uuid of "8f32f043-c3c9-e7f8-f947-4e7f989c05d3", which
> indicated it was a block from an older filesystem. The reason that
> log recovery didn't replay it was that the LSN in the XARM block was
> larger than the LSN of the transaction being replayed, and so the
> block was not overwritten by log recovery.
> 
> Hence, log recovery cant blindly trust the magic number and LSN in
> the block - it must verify that it belongs to the filesystem being
> recovered before using the LSN. i.e. if the UUIDs don't match, we
> need to unconditionally recovery the change held in the log.
			  recover
 
> This patch was first tested on a block device that was repeatedly
> causing xfs/182 to fail with the same failure on the same block with
> the same directory read corruption signature (i.e. XARM block). It
> did not fail, and hasn't failed since.
> 
> Signed-off-by: Dave Chinner <dchinner@redhat.com>

Looks good to me.
Reviewed-by: Ben Myers <bpm@sgi.com>

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

  reply	other threads:[~2013-09-24 17:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24  6:01 [PATCH 0/5] xfs: fixes for 3.12-rc3 Dave Chinner
2013-09-24  6:01 ` [PATCH 1/5] xfs: don't try to mark uncached buffers stale on error Dave Chinner
2013-09-24 15:31   ` Mark Tinguely
2013-09-24 15:33   ` Ben Myers
2013-09-24 20:32     ` Dave Chinner
2013-09-24 20:59       ` Ben Myers
2013-09-25  0:31         ` Dave Chinner
2013-09-24  6:01 ` [PATCH 2/5] xfs: lock the AIL before removing the buffer item Dave Chinner
2013-09-24 16:12   ` Mark Tinguely
2013-09-24  6:01 ` [PATCH 3/5] xfs: asserting lock not held during freeing not valid Dave Chinner
2013-09-24 17:17   ` Mark Tinguely
2013-09-24  6:01 ` [PATCH 4/5] xfs: fix XFS_IOC_FREE_EOFBLOCKS definition Dave Chinner
2013-09-24 16:13   ` Mark Tinguely
2013-09-24  6:01 ` [PATCH 5/5] xfs: log recovery lsn ordering needs uuid check Dave Chinner
2013-09-24 17:14   ` Ben Myers [this message]
2013-09-24 17:46 ` [PATCH 0/5] xfs: fixes for 3.12-rc3 Ben Myers

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=20130924171446.GG1935@sgi.com \
    --to=bpm@sgi.com \
    --cc=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.