[dm-devel] [PATCH] fix writing to the filesystem after unmount

[Zdenek Kabelac]

Dne 08. 09. 23 v 12:20 Jan Kara napsal(a):
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20230908/24922401/attachment.htm>