Re: [BULK] Re: [PATCH] xfstests 311: test fsync with dm flakey V2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.  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,

Josef

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




[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux