From: Miklos Szeredi <miklos@szeredi.hu>
To: Bernd Schubert <bernd.schubert@fastmail.fm>
Cc: Joanne Koong <joannelkoong@gmail.com>,
linux-fsdevel@vger.kernel.org, josef@toxicpanda.com,
jefflexu@linux.alibaba.com, laoar.shao@gmail.com,
kernel-team@meta.com
Subject: Re: [PATCH v6 1/2] fuse: add optional kernel-enforced timeout for requests
Date: Mon, 2 Sep 2024 13:11:31 +0200 [thread overview]
Message-ID: <CAJfpegsGH06H1tEbV3TDFiwC2d9Kfr-da288mqT83yo85naqGg@mail.gmail.com> (raw)
In-Reply-To: <1c7c9f00-8e94-4a98-a3d4-a3610d35e744@fastmail.fm>
On Mon, 2 Sept 2024 at 12:50, Bernd Schubert <bernd.schubert@fastmail.fm> wrote:
> In case of distributed servers, it can easily happen that one server has
> an issue, while other servers still process requests. Especially when
> these are just requests that read/getattr/etc and do not write, i.e.
> accessing the stuck server is not needed by other servers. So in my
> opinion not so unlikely. Although for such cases not difficult to
> timeout within the fuse server.
Exactly. Normally the kernel should not need to time out fuse
requests, and it might be actively detrimental to do so.
The main case this wants to solve is a deadlocked server due to
programming error, AFAICS. And this would only work in environments
where requests are guaranteed to complete within some time period.
So if the server needs to handle request timeouts, then it should
*not* rely on the kernel timeout. The kernel timeout should be a
safeguard against broken or malicious servers, not an aid to implement
request timeouts.
Thanks,
Miklos
next prev parent reply other threads:[~2024-09-02 11:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 16:26 [PATCH v6 0/2] fuse: add timeout option for requests Joanne Koong
2024-08-30 16:26 ` [PATCH v6 1/2] fuse: add optional kernel-enforced timeout " Joanne Koong
2024-09-02 10:37 ` Miklos Szeredi
2024-09-02 10:50 ` Bernd Schubert
2024-09-02 11:11 ` Miklos Szeredi [this message]
2024-09-03 17:25 ` Joanne Koong
2024-09-03 22:37 ` Bernd Schubert
2024-09-04 17:23 ` Joanne Koong
2024-09-17 22:00 ` Bernd Schubert
2024-09-18 7:29 ` Miklos Szeredi
2024-09-18 9:12 ` Bernd Schubert
2024-09-27 19:36 ` Joanne Koong
2024-09-28 8:43 ` Bernd Schubert
2024-10-01 17:03 ` Joanne Koong
2024-10-01 17:12 ` Joanne Koong
2024-10-07 18:39 ` Joanne Koong
2024-10-07 20:02 ` Bernd Schubert
2024-10-08 16:26 ` Joanne Koong
2024-10-08 19:00 ` Joanne Koong
2024-08-30 16:26 ` [PATCH v6 2/2] fuse: add default_request_timeout and max_request_timeout sysctls Joanne Koong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJfpegsGH06H1tEbV3TDFiwC2d9Kfr-da288mqT83yo85naqGg@mail.gmail.com \
--to=miklos@szeredi.hu \
--cc=bernd.schubert@fastmail.fm \
--cc=jefflexu@linux.alibaba.com \
--cc=joannelkoong@gmail.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@meta.com \
--cc=laoar.shao@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).