xfs
[Top] [All Lists]

Re: Kernel 2.6.30.4 XFS(..?) regression (& with/2.6.31-rc6)

To: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Subject: Re: Kernel 2.6.30.4 XFS(..?) regression (& with/2.6.31-rc6)
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sun, 23 Aug 2009 18:45:04 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.0908221659030.23463@xxxxxxxxxxxxxxxx>
References: <alpine.DEB.2.00.0908110624420.22426@xxxxxxxxxxxxxxxx> <20090816022331.GA2309@xxxxxxxxxxxxx> <alpine.DEB.2.00.0908171024380.12533@xxxxxxxxxxxxxxxx> <alpine.DEB.2.00.0908220624440.30321@xxxxxxxxxxxxxxxx> <20090822142550.GA10003@xxxxxxxxxxxxx> <alpine.DEB.2.00.0908221044420.30321@xxxxxxxxxxxxxxxx> <20090822201558.GA17955@xxxxxxxxxxxxx> <alpine.DEB.2.00.0908221645440.20848@xxxxxxxxxxxxxxxx> <20090822205502.GA18904@xxxxxxxxxxxxx> <alpine.DEB.2.00.0908221659030.23463@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.19 (2009-01-05)
Ok, let's see where errors could happen then.

There are four theoretical possibilities:

 (a) XFS
 (b) loop driver
 (c) crypto loop code
 (d) block layer

Or combinations thereof.

I would take (a) and (d) as more unlikely as they tend to get used much
more and I would have heard more bug reports already.

The cryptoloop code hasn't changed at all since 2.6.29.

The loop code howver has a very interesting commit just after 2.6.39:

commit 68db1961bbf4e16c220ccec4a780e966bc1fece3
Author: Nikanth Karthikesan <knikanth@xxxxxxx>
Date:   Tue Mar 24 12:29:54 2009 +0100

    loop: support barrier writes

Can you try reverting this one (it cleanly reverse-applies against
2.6.30 and current mainline) and see if that makes a difference?

<Prev in Thread] Current Thread [Next in Thread>