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