On Fri 08-09-23 11:29:40, Zdenek Kabelac wrote:Dne 08. 09. 23 v 9:32 Jan Kara napsal(a):On Thu 07-09-23 14:04:51, Mikulas Patocka wrote:On Thu, 7 Sep 2023, Christian Brauner wrote:I think we've got too deep down into "how to fix things" but I'm not 100%We did.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?I think it's an issue if the administrator writes a script that unmounts a filesystem and then copies the underyling block device somewhere. Or a script that unmounts a filesystem and runs fsck afterwards. Or a script that unmounts a filesystem and runs mkfs on the same block device.Well, e.g. e2fsprogs use O_EXCL open so they will detect that the filesystem hasn't been unmounted properly and complain. Which is exactly what should IMHO happen.
I'd likely propose in this particular state of unmounting of a frozen filesystem to just proceed - and drop the frozen state together with release filesystem and never issue any ioctl from such filelsystem to the device below - so it would not be a 100% valid unmount - but since the freeze should be nearly equivalent of having a proper 'unmount' being done - it shoudn't be causing any harm either - and all resources associated could be 'released. IMHO it's correct to 'drop' frozen state for filesystem that is not going to exist anymore (assuming it's the last such user)This option was also discussed in the past and it has nasty consequences as well. Cleanly shutting down a filesystem usually needs to write to the underlying device so either you allow the filesystem to write to the device on umount breaking assumptions of the user who froze the fs or you'd have to implement a special handling for this case for every filesystem to avoid the writes (and put up with the fact that the filesystem will appear as uncleanly shutdown on the next mount). Not particularly nice either...
I'd say there are several options and we should aim towards the variant which is most usable by normal users.
Making hyper complex unmount rule logic that basically no user-space tools around Gnome/KDE... are able to handle well and getting it to the position where only the core kernel developer have all the 'wisdom' to detect and decode system state and then 'know what's going on' isn't the favourite goal here.
Freeze should be getting the filesystem into 'consistent' state - filesystem should be able to 'easily' recover and finish all the ongoing 'unfinished' process with the next mount without requiring full 'fsck' - otherwise it would be useless for i.e. snapshot.
So to me this looks like the win-win strategy where we basically do not loose any information and we also do not leak kernel resources - since i..e in case of DM devices - the underlying DM device might have already changed disk characteristics anyway.
If the developers then believe - that 'more variants' of complex
behavior are necessary - then kernel could have some sysfs
parameter to configure some 'more advanced' logic i.e. keep 'fs
mounted' for those skilled admins who are able to go through the
deepest corners here - but other then that plain 'umount'
should really go with the meaning of a) manages to umount and
release a device b) in other case reports to a user there is
still something holding device....
Regards
Zdenek
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
