Re: [PATCH v4 0/2] fuse: add timeout option for requests

[Bernd Schubert <bernd.schubert@fastmail.fm>]

On 8/21/24 15:47, Miklos Szeredi wrote:
> On Wed, 14 Aug 2024 at 01:23, Joanne Koong <joannelkoong@gmail.com> wrote:
>>
>> There are situations where fuse servers can become unresponsive or take
>> too long to reply to a request. Currently there is no upper bound on
>> how long a request may take, which may be frustrating to users who get
>> stuck waiting for a request to complete.
>>
>> This patchset adds a timeout option for requests and two dynamically
>> configurable fuse sysctls "default_request_timeout" and "max_request_timeout"
>> for controlling/enforcing timeout behavior system-wide.
>>
>> Existing fuse servers will not be affected unless they explicitly opt into the
>> timeout.
> 
> I sort of understand the motivation, but do not clearly see why this
> is required.
> 
> A well written server will be able to do request timeouts properly,
> without the kernel having to cut off requests mid flight without the
> knowledge of the server.  The latter could even be dangerous because
> locking guarantees previously provided by the kernel do not apply
> anymore.
> 
> Can you please explain why this needs to be done by the client
> (kernel) instead of the server (userspace)?

I don't know about Joannes motivation, I see two use cases

- You suggested yourself that timeouts might be a (non-ideal) 
solution to avoid page copies on writeback
https://lore.kernel.org/linux-mm/CAJfpegt_mEYOeeTo2bWS3iJfC38t5bf29mzrxK68dhMptrgamg@mail.gmail.com/raw

- Would probably be a solution for this LXCFS issue
https://lore.kernel.org/lkml/a8d0c5da-6935-4d28-9380-68b84b8e6e72@shopee.com/
(although I don't fully understand the issue there yet)


Thanks,
Bernd