On Fri, Apr 26, 2013 at 06:32:14PM -0400, Josef Bacik wrote: > On Fri, Apr 26, 2013 at 04:05:22PM -0600, Dave Chinner wrote: > > On Fri, Apr 26, 2013 at 03:31:01PM -0400, Josef Bacik wrote: > > > On Thu, Apr 25, 2013 at 08:12:14PM -0600, Dave Chinner wrote: > > > > > Ok so I think I'll just make this test do all the iterations of the > > > > > fsync tester > > > > > with and without --nolockfs, since without --nolockfs I'm still > > > > > seeing problems, > > > > > does that sound reasonable? > > > > > > > > Sounds like a fine plan to me ;) > > > > > > > > > > Btw its test 19 O_DIRECT that gives me a 0 length file, the buffered case > > > is > > > fine. The test just does a randomly sized sub-block sized write over and > > > over > > > again for a random number of times and fsync()'s in there randomly. The > > > number > > > is 3072 because that's the largest inline extent we can have in btrfs, I > > > added > > > it specifically to test our inline extent logging. Thanks, > > > > Interesting - it only runs fsync every 8 iterations of the loop. Can > > you check that it is running enough loops to execute a fsync? > > > > If the loop doesn't fsync it still fsyncs before the program exits.
Doh! I noticed that yesterday but forgot about it. Not enough coffee. I'll have a closer look, then. > Side note I once wasted a week because Chris's fsync tester > _didn't_ fsync() before exit so it would tell you a md5sum of a > file that hadn't fsync()ed before the md5sum and I just assumed > btrfs was broken. This test does not make this mistake for that > reason :). Thanks, I think we've all made mistakes like that at least once.... :/ Cheers, Dave. -- Dave Chinner [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
