----- 原始邮件 ----- > 发件人: "Dave Chinner" <david@xxxxxxxxxxxxx> > 收件人: "Zirong Lang" <zlang@xxxxxxxxxx> > 抄送: "Eryu Guan" <eguan@xxxxxxxxxx>, fstests@xxxxxxxxxxxxxxx, sandeen@xxxxxxxxxx, cem@xxxxxxxxxx > 发送时间: 星期三, 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@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 > -- 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
