[dm-devel] trouble with generic/081

[Zdenek Kabelac]

Dne 9.1.2017 v 15:54 Eric Sandeen napsal(a):
> On 1/9/17 8:22 AM, Zdenek Kabelac wrote:
>> But could anyone from XFS specify -  why  umount is causing some
>> 'more' damage, then  no umount at all ?
>
> Please reread this thread...  it /started/ with problems
> /caused by unmount/ for Christoph.
>
> It's not that unmount damages the filesystem per se; it damages the
> /system/ when it uncovers the underlying mountpoint and applications
> continue writing without error, to the /wrong filesystem/.
>
> Further, if unmount requires IO that can't complete due to ENOSPC,
> then launching the unmount behind the admin's back may cause other
> problems when it gets detached from the namespace.
>
> Christoph later clarified:
>
>> Even on a production system I'd much rather have a shutdown XFS fs
>> than LVM trying to unmount, probably hanging because there are busy
>> fds on the fs, and if not the application might not write to another
>> fs becaus of this.  It's just an amazingly stupid idea.
>
> And again:
>
>> invi[si]bly unmounting
>> a file system behind the users back is actively harmful, as it is
>> contradicting the principle of least surprise, and the xfstests mess
>> is one simple example for it.
> ...
>> [ it's undesirable to ] unmount and expose the namespace below it,
>> which the administrator has probably intentionally hid.
>
>> Even worse unmount may trigger further writes and with fses not
>> handling them the fs might now be stuck after being detached from
>> the namespace without a way for the admin to detect or recover this.
>
> Dave agreed:
>
>> And my 2c worth on the "lvm unmounting filesystems on error" - stop
>> it, now. It's the wrong thing to do, and it makes it impossible for
>> filesystems to handle the error and recover gracefully when
>> possible.
>
> Now, as for:
>
>> Is xfs refusing to umount 'erroring' device ?
>
> I'm not sure what you mean by this.  XFS never unmounts itself.
> If you're asking if an XFS filesystem in an error state (i.e., shutdown,
> or with failing IOs) can unmount - yes, it is possible to unmount
> a filesystem in this state.  The administrator can make that choice.
>
>
>
> You've had two preeminent XFS developers ask repeatedly that
> you stop unmounting xfs from lvm2.  I really wish you would take their
> advice.


As said already said couple times -   lvm2 WILL provide this feature.
For sure - I'll repeat again - it will get there.


>
> We need to work together to ensure that these subsystems react
> in the best possible way to overprovisioned storage, and give the admin
> the best chance at recovery without more adverse affects.  For the reasons
> stated above, unmounting the filesystem does not achieve this goal.
>
> It leads to application IO to wrong filesystems (quite possibly root),
> detached filesystems which can no longer be administered, possible hung
> unmounts, etc.  Automatic unmount is the wrong reaction, please stop doing
> it.

I do get this - but we have 2 cases - each has it's merit.

You have the case were application will write to 'different' filesystem,
while in other cases user will be able to continue to use their filesystem
and cause irreparable filesystem damage (whatever you want to believe
is failure if thin-pool or filesystem).

So I believe it's upto a user to be able to pick which version he
prefers - and that's  why  lvm2 will provide this  behavior configurable.

You could of course do any other jobs - i.e. call fstrim  in the hook.

Regards

Zdenek