Re: [PATCH v4 2/2] xfs/006: new case to test xfs fail_at_unmount error handling

[Zirong Lang <zlang@redhat.com>]

Hi Dave

----- 原始邮件 -----
> 发件人: "Dave Chinner" <david@fromorbit.com>
> 收件人: "Eryu Guan" <eguan@redhat.com>
> 抄送: "Zorro Lang" <zlang@redhat.com>, fstests@vger.kernel.org, sandeen@redhat.com, cem@redhat.com
> 发送时间: 星期三, 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@fromorbit.com
>