On Thu, Jun 23, 2011 at 04:09:00PM +1000, Dave Chinner wrote:
> On Thu, Jun 23, 2011 at 03:08:19PM +1000, Dave Chinner wrote:
> > On Wed, Apr 20, 2011 at 11:36:14AM -0400, Christoph Hellwig wrote:
> > > On Wed, Apr 20, 2011 at 09:57:22AM -0500, bpm@xxxxxxx wrote:
> > > > Wish I did. The test case that discovered this only applies to CXFS. I
> > > > would have liked to post a test case for XFS but decided that this has
> > > > been on my TODO list for too long already. Looks to me like it has to
> > > > be related to the inode size, so you quit probing buffers after the
> > > > first. Maybe some discussion will ring some bells for somebody.
> > >
> > > It would be really good to have one, but the actual patch looks good
> > > enough that I'd consider putting it in. I can assumes you ran
> > > xfstests with various small blocksize options for both the test
> > > and scratch device and it didn't show any regressions?
> > I've been running this patch for quite some time, but having just
> > upgraded to the latest xfstests, this patch is causing fsx failures
> > in tests 075 091 112 127 and 231 on 3.0-rc4 on x86_64 with default
> > mkfs and mount parameters. fsx passes again with this patch removed
> > from my test stack....
> Seems I spoke too soon - the fsx failures seems to be intermittent,
> and it was just chance that my bisect landed on this patch....
I've reproduced the fsx failure with an unmodified, top-of-tree
Linus 3.0-rc kernel, so it's time to start the mainline bisect dance