Re: Wrapped journal record corruption on read at recovery - patch attached (was Re: XFS corruption with failover)

From: Christoph Hellwig <hch@infradead.org>
To: Andy Poling <andy@realbig.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	John Quigley <jquigley@cleversafe.com>,
	xfs@oss.sgi.com
Subject: Re: Wrapped journal record corruption on read at recovery - patch attached (was Re: XFS corruption with failover)
Date: Wed, 14 Oct 2009 09:20:30 -0400	[thread overview]
Message-ID: <20091014132030.GB15001@infradead.org> (raw)
In-Reply-To: <alpine.DEB.2.00.0910131853200.11546@andydesk>

On Tue, Oct 13, 2009 at 07:29:00PM -0500, Andy Poling wrote:
> Agreed.  I aimed for the smallest possible patch, thinking it might increase
> the likelihood of acceptance.  :-)

Heh.  In the Linux world and especially for this project we don't have
any problem with large fixes as long as they are well-explained and
self-contained, epecially if they are as well-documented as yours.

> I think the complexity here stems from an uncertainty (as we prepare for the
> "second" read) whether there was a first read or not.  As the code reads
> today, if there is data before the end, the first read is done and offset has
> been set.  If not, offset is NULL.
>
> It seems like the more elegant approach would be to set offset before the
> first read, and then update it if the first read takes place (in case it was
> unaligned).  That also gets rid of bufaddr, and seems like it might read
> better.

Yeah.  Note that in Linux 2.6.29 I did some changes in that are to
take the read and offset calculation into a common helper, so if the
changes become larger we might see some cosmetic difference between
older and newer kernels.

>> I suspect we might even be able to come up with a small enough testcase
>> for this for xfsqa, we just need to make sure logs are aligned and then
>> find a good enough heuristic to reproduce log wrapping.
>
> I don't know if it would be appropriate in that context, but maybe a tool to
> process an unwrapped log and wrap it would be easier?

We have a tool called loggen to produce log traffic as part of the QA
test suite.  We could try to use it to reproduce this case.  The most
important bit is that we work on a filesystem that actually requires
the alignment bits, that is one using a larger log sector size.  Just
curious, what is the value of sb_logsectlog for your test fs?

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