On Wed, 11 May 2022 at 03:31, Daniil Lunev <[email protected]> wrote:
>
> Force unmount of fuse severes the connection between FUSE driver and its
> userspace counterpart.
Why is forced umount being used in the first place?
Thanks,
Miklos
On Wed, May 11, 2022 at 5:07 PM Miklos Szeredi <[email protected]> wrote:
>
> On Wed, 11 May 2022 at 03:31, Daniil Lunev <[email protected]> wrote:
> >
> > Force unmount of fuse severes the connection between FUSE driver and its
> > userspace counterpart.
>
> Why is forced umount being used in the first place?
To correctly suspend-resume. We have been using this force unmount historically
to circumvent the suspend-resume issues which periodically occur with fuse.
We observe FUSE rejecting to remount the device because of the issue this
patchset attempts to address after the resume if there are still open
file handles
holding old super blocks. I am not sure if fuse's interaction with suspend is
something that has been resolved systematically (we are also trying to
figure that
out). Regardless of that, doing force unmount of a mount point is a legitimate
operation, and with FUSE it may leave the system in a state that is returning
errors for other legitimate operations.
Thanks,
Daniil
On Wed, 11 May 2022 at 09:36, Daniil Lunev <[email protected]> wrote:
>
> On Wed, May 11, 2022 at 5:07 PM Miklos Szeredi <[email protected]> wrote:
> >
> > On Wed, 11 May 2022 at 03:31, Daniil Lunev <[email protected]> wrote:
> > >
> > > Force unmount of fuse severes the connection between FUSE driver and its
> > > userspace counterpart.
> >
> > Why is forced umount being used in the first place?
>
> To correctly suspend-resume. We have been using this force unmount historically
> to circumvent the suspend-resume issues which periodically occur with fuse.
> We observe FUSE rejecting to remount the device because of the issue this
> patchset attempts to address after the resume if there are still open
> file handles
> holding old super blocks. I am not sure if fuse's interaction with suspend is
> something that has been resolved systematically (we are also trying to
> figure that
> out).
No progress has been made in the past decade with regard to suspend.
I mainly put that down to lack of interest.
> Regardless of that, doing force unmount of a mount point is a legitimate
> operation, and with FUSE it may leave the system in a state that is returning
> errors for other legitimate operations.
It is a legitimate operation, but one that is not guaranteed to leave
the system in a clean state.
Thanks,
Miklos
> No progress has been made in the past decade with regard to suspend.
> I mainly put that down to lack of interest.
>
That is unfortunate.
> It is a legitimate operation, but one that is not guaranteed to leave
> the system in a clean state.
Sure, I don't think I can argue about it. The current behaviour is a problem,
however, since there is no other way to ensure the system can suspend
reliably but force unmount - we try normal unmount first and proceed with
force if that fails. Do you think that the approach proposed in this patchset
is a reasonable path to mitigate the issue?
Thanks,
Daniil