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@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
