On Mon, Aug 26, 2024 at 11:49 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Mon, 26 Aug 2024 at 22:33, Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > > > > There are situations where fuse servers can become unresponsive or > > stuck, for example if the server is in a deadlock. Currently, there's > > no good way to detect if a server is stuck and needs to be killed > > manually. > > > > This patchset adds a timeout option for requests where if the server does not > > reply to the request by the time the timeout elapses, the connection will be > > aborted. This patchset also adds 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. > > This last paragraph seems to contradict the purpose of the system-wide > maximum timeout. If the server can opt out of timeouts, then > enforcing a maximum timeout is pointless. > > Am I missing something? Ah by that last paragraph, my intention was to convey that for existing systems that run fuse servers, pre-existing behavior will stay as is and they don't have to worry about any functional changes from this patchset if they don't explicitly opt into it. I'll change this wording to "Existing systems running fuse servers will not be affected unless they explicitly opt into the timeout". Thanks, Joanne > > Thanks, > Miklos
