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

[Dave Chinner <david@fromorbit.com>]

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
attribute.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com