On Tue, Jun 21, 2016 at 03:08:18PM +0800, Eryu Guan wrote: > On Mon, Jun 20, 2016 at 09:24:33PM +0800, Zorro Lang wrote: > > +# real QA test starts here > > +_supported_fs xfs > > +_supported_os Linux > > +_require_dm_target error > > +_require_scratch > > + > > +_scratch_mkfs > $seqres.full 2>&1 > > +_require_fs_sysfs $SCRATCH_DEV error/fail_at_unmount > > Usually we call _require_xxx before mkfs and do the real test, a comment > to explain why we need to mkfs first would be good. Ok, so why do we need to test the scratch device for this sysfs file check? We've already got the test device mounted, and filesystems tend to present identical sysfs control files for all mounted filesystems. i.e. this _require_fs_sysfs() function could just drop the device and check the test device for whether the sysfs entry exists. If it doesn't, then the scratch device isn't going to have it, either. > > +# umount will cause XFS try to writeback something to root inode. > > +# So after load error table, it can trigger umount fail. > > +_dmerror_load_error_table > > +_dmerror_unmount > > Unmount still doesn't hang for me when I set fail_at_unmount to 0. Maybe > it's hard to hit the correct timing everytime. I wouldn't expect unmount to hang if you just "mount/pull device/unmount" like this test appears to be doing. The filesystem has to have dirty metadata for it to reliably hang. run a short fsstress load, pull the device while it is running, then unmount. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
