On Wed 06-09-23 18:52:39, Mikulas Patocka wrote: > On Wed, 6 Sep 2023, Christian Brauner wrote: > > On Wed, Sep 06, 2023 at 06:01:06PM +0200, Mikulas Patocka wrote: > > > > > BTW. what do you think that unmount of a frozen filesystem should properly > > > > > do? Fail with -EBUSY? Or, unfreeze the filesystem and unmount it? Or > > > > > something else? > > > > > > > > In my opinion we should refuse to unmount frozen filesystems and log an > > > > error that the filesystem is frozen. Waiting forever isn't a good idea > > > > in my opinion. > > > > > > But lvm may freeze filesystems anytime - so we'd get randomly returned > > > errors then. > > > > So? Or you might hang at anytime. > > lvm doesn't keep logical volumes suspended for a prolonged amount of time. > It will unfreeze them after it made updates to the dm table and to the > metadata. So, it won't hang forever. > > I think it's better to sleep for a short time in umount than to return an > error. I think we've got too deep down into "how to fix things" but I'm not 100% sure what the "bug" actually is. In the initial posting Mikulas writes "the kernel writes to the filesystem after unmount successfully returned" - is that really such a big issue? Anybody else can open the device and write to it as well. Or even mount the device again. So userspace that relies on this is kind of flaky anyway (and always has been). I understand the need for userspace to make sure the device is not being modified to do its thing - but then it should perhaps freeze the bdev if it wants to be certain? Or at least open it O_EXCL to make sure it's not mounted? WRT the umount behavior for frozen filesystem - as Al writes it's a tricky issue and we've been discussing that several times over the years and it never went anywhere because of nasty corner-cases (which current behavior also has but trading one nasty case for another isn't really a win). Now that we distinguish between kernel-initiated freeze (with well defined freeze owner and lifetime) and userspace-initiated freeze, I can image we'd make last unmount of the superblock wait for the kernel-initiated freeze to thaw. But as Al writes with lazy unmounts, bind mounts in multiple namespaces etc. I'm not sure such behavior brings much value... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
