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 again..... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
