From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: inode buffers may not be valid during recovery readahead
Date: Fri, 30 Aug 2013 13:15:20 -0500 [thread overview]
Message-ID: <20130830181520.GD1935@sgi.com> (raw)
In-Reply-To: <1377567577-24312-1-git-send-email-david@fromorbit.com>
Dave,
On Tue, Aug 27, 2013 at 11:39:37AM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> CRC enabled filesystems fail log recovery with 100% reliability on
> xfstests xfs/085 with the following failure:
Unfortunately I have not been able to hit this one... not sure why.
> XFS (vdb): Mounting Filesystem
> XFS (vdb): Starting recovery (logdev: internal)
> XFS (vdb): Corruption detected. Unmount and run xfs_repair
> XFS (vdb): bad inode magic/vsn daddr 144 #0 (magic=0)
> XFS: Assertion failed: 0, file: fs/xfs/xfs_inode_buf.c, line: 95
>
> The problem is that the inode buffer has not been recovered before
> the readahead on the inode buffer is issued. The checkpoint being
> recovered actually allocates the inode chunk we are doing readahead
> from, so what comes from disk during readahead is essentially
> random and the verifier barfs on it.
>
> This inode buffer readahead problem affects non-crc filesystems,
> too, but xfstests does not trigger it at all on such
> configurations....
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
I've been mulling this one over for a bit, and I'm not quite sure this
is correct:
My feeling is that in light of commit 9222a9cf, if we do take part of a
buffer back in time, the write verifier should fail. I think for a v2
inode the read and write verifiers should both be disabled for the
duration of recovery. For v3 inodes, I suspect the current situation
where we do use write verifiers is broken in the same way, at least
until we pull in 'xfs: prevent transient corrupt states during log
recovery', which, as you say, won't fix the problem for the v2 inode.
I'll pull this in and send a patch to that effect.
Reviewed-by: Ben Myers <bpm@sgi.com>
Regards,
Ben
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-08-30 18:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-27 1:39 [PATCH] xfs: inode buffers may not be valid during recovery readahead Dave Chinner
2013-08-30 18:15 ` Ben Myers [this message]
2013-08-31 6:14 ` Dave Chinner
2013-09-03 22:17 ` Ben Myers
2013-09-03 23:50 ` 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=20130830181520.GD1935@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.