Hi Dave ----- 原始邮件 ----- > 发件人: "Dave Chinner" <david@xxxxxxxxxxxxx> > 收件人: "Eryu Guan" <eguan@xxxxxxxxxx> > 抄送: "Zorro Lang" <zlang@xxxxxxxxxx>, fstests@xxxxxxxxxxxxxxx, sandeen@xxxxxxxxxx, cem@xxxxxxxxxx > 发送时间: 星期三, 2016年 6 月 22日 上午 8:00:40 > 主题: Re: [PATCH v4 2/2] xfs/006: new case to test xfs fail_at_unmount error handling > > 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. Hmm... at first I thought about if I should use TEST_DEV to do _require_fs_sysfs checking. But I'm not sure if different devices maybe bring different sysfs attributes in, if someone make a special device in one case? So I give one more argument about device name. > > > > +# 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. The umount doesn't hang because in _dmerror_load_error_table(), it use "--nolockfs" option for dmsetup suspend operation. If drop this option, umount will hang. As I test, mount/pull device/unmount can cause a hang, because unmount will try to writeback something to root inode? But yes, do more fsstress load can help to trigger the hang easier:) I haven't known why "--nolockfs" will cause this situation. "--nolockfs" will make suspend don't attempt to synchronize filesystem when suspending a device. Maybe some uncompleted I/Os cause xfs shutdown, after resume error table? If you glad to explain it for us, that's my pleasure:-) Thanks, Zorro > > 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
