On Thu, Apr 25, 2013 at 07:08:29PM -0600, Dave Chinner wrote:
> On Thu, Apr 25, 2013 at 08:24:04PM -0400, Josef Bacik wrote:
> > On Thu, Apr 25, 2013 at 04:45:56PM -0600, Dave Chinner wrote:
> > > On Thu, Apr 25, 2013 at 10:12:56AM -0400, Josef Bacik wrote:
> .....
> > > > + $here/src/fsync-tester -s $SEED -r -t $test_num $extra $testfile
> > > > + if [ $? -ne 0 ]; then
> > > > + _unmount_flakey
> > > > + _cleanup
> > > > + exit
> > > > + fi
> > > > +
> > > > + _md5_checksum $testfile
> > > > + _drop_writes
> > > > + _unmount_flakey
> > >
> > > So, _drop_writes suspends the dm-flakey device, freezes the
> > > filesystem, turns off writes then thaws the filesystem, right?
> > >
> > > If so, doesn't that mean you're not actually testing fsync() as the
> > > freeze will effectively sync the entire filesystem before you start
> > > dropping writes?
> > >
> > > I can see why you want to stop unmount from writing back metadata to
> > > simulate a crash, but if you've already frozen the filesystem then
> > > writeback has already occurred before you stop the writes. So I
> > > can't see how this is actually testing fsync - what it appears to be
> > > testing is the fileystem freeze code...
> > >
> > > [ This is precisely the issue that XFS shutdown ioctls deal with to
> > > trigger an immediate forced shutdown of the filesystem that prevents
> > > *any* further writes from being issued by the filesystem - no sync
> > > operations get in the way and change the state of the filesystem
> > > after then fsync call, so we know that what is on disk is what was
> > > written by the sync/fsync calls being tested.
> > >
> > > This is how we test sync/fsync in other XFS tests (e.g.
> > > xfs/137-140), and this is the reason why us XFS people have
> > > suggested that other filesystems should implement the ioctls for
> > > this functionality rather than try to invent new ways of trying
> > > to stop filesystems from writing back dirty metadata for fsync/sync
> > > testing....
> > >
> > > Besides, if a corruption is detected, you need a method of stopping
> > > all dirty metadata from being written back in the filesystem to
> > > prevent propagation of the corruption. These ioctls should just be
> > > an interface into that mechanism. ]
> > >
> >
> > So I need to look at what this does. I don't think it freezes the file
> > system,
>
> `dmsetup suspend` ends up in dm_suspend(). This calls lock_fs(), which
> calls freeze_bdev()....
>
> If you do `dmsetup suspend --nolockfs` then it won't freeze the
> filesystem during the suspend...
>
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?
> > because I've run this test and I definitely have a tree log on the file
> > system
> > after I unmount, which means we didn't actually sync(). Either that or
> > freeze()
> > is broken for btrfs and it's not actually causing the transaction to commit.
>
> Entirely possible.
>
> /me muses randomly about why we call them bugs when they are almost
> always layered like onions.....
>
No kidding, I've spent all week unraveling various problems that this test has
uncovered.
> > If
> > it turns out that it is freeze() then it's not actually a fsync tester, but
> > it
> > seems to still be a valid test since it's definitely causing problems for
> > all
> > the file systems I've tested and I'll leave this as it is and then write
> > another
> > real fsync tester.
>
> ext4 as well?
>
Yeah ext4 blows up right after the first test, the md5sums match but fsck
complains loudly.
> > > How long does this take to run? It seems like the quick group would
> > > be appropriate if it takes less than a minute. Also, fsync tests
> > > fall under the category of "metadata" and "log", so they probably
> > > should be added, too.
> > >
> >
> > It takes 66 seconds to run on btrfs, is that fast enough for quick? I'll
> > add
> > metadata and log to the list as well. Thanks for the thorough review,
>
> Probably a bit too long for my liking - it won't be quick when there
> are several instances of VMs running xfstests on the same set of
> spindles....
>
Yeah I had quick originally but when I finally got it to run I took it out since
66 seconds seemed too long to me. Thanks,
Josef
|