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

[Zirong Lang <zlang@redhat.com>]

----- 原始邮件 -----
> 发件人: "Dave Chinner" <david@fromorbit.com>
> 收件人: "Zirong Lang" <zlang@redhat.com>
> 抄送: "Eryu Guan" <eguan@redhat.com>, fstests@vger.kernel.org, sandeen@redhat.com, cem@redhat.com
> 发送时间: 星期三, 2016年 6 月 22日 上午 11:04:22
> 主题: Re: [PATCH v4 2/2] xfs/006: new case to test xfs fail_at_unmount error handling
> 
> On Tue, Jun 21, 2016 at 09:42:53PM -0400, Zirong Lang wrote:
> > 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?
> 
> when dm loads the new table, it first suspends the device. This
> freezes the filesystem, which means it completely clean. Hence after
> this there is nothing to write back on unmount and it doesn't hang.
> 
> Using --nolockfs means dm does not suspend the device and hence the
> filesystem is not frozen before loading the new table. That means
> unmount occurs with dirty metadata still in memory, and so umount
> will try to write it and behaviour is then determined by the sysfs

No, no, I think there're some misunderstand. Looks like you thought with
--nolockfs umount will hang. But the truth is:

When fail_at_unmount=0,
  Without --nolockfs option, umount will hang(fail_at_unmount=0).
  With --nolockfs option, umount will not hang.

Thanks,
Zorro

> attribute.
> 
> Cheers,
> 
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>