* [PATCH v7 1/3] fs_parser: add fsparam_u16 helper
2024-10-07 18:42 [PATCH v7 0/3] fuse: add kernel-enforced request timeout option Joanne Koong
@ 2024-10-07 18:42 ` Joanne Koong
2024-10-07 18:42 ` [PATCH v7 2/3] fuse: add optional kernel-enforced timeout for requests Joanne Koong
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Joanne Koong @ 2024-10-07 18:42 UTC (permalink / raw)
To: miklos, linux-fsdevel
Cc: josef, bernd.schubert, jefflexu, laoar.shao, kernel-team
Add a fsparam helper for unsigned 16 bit values.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
---
fs/fs_parser.c | 14 ++++++++++++++
include/linux/fs_parser.h | 9 ++++++---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/fs/fs_parser.c b/fs/fs_parser.c
index 24727ec34e5a..0e06f9618c89 100644
--- a/fs/fs_parser.c
+++ b/fs/fs_parser.c
@@ -210,6 +210,20 @@ int fs_param_is_bool(struct p_log *log, const struct fs_parameter_spec *p,
}
EXPORT_SYMBOL(fs_param_is_bool);
+int fs_param_is_u16(struct p_log *log, const struct fs_parameter_spec *p,
+ struct fs_parameter *param, struct fs_parse_result *result)
+{
+ int base = (unsigned long)p->data;
+ if (param->type != fs_value_is_string)
+ return fs_param_bad_value(log, param);
+ if (!*param->string && (p->flags & fs_param_can_be_empty))
+ return 0;
+ if (kstrtou16(param->string, base, &result->uint_16) < 0)
+ return fs_param_bad_value(log, param);
+ return 0;
+}
+EXPORT_SYMBOL(fs_param_is_u16);
+
int fs_param_is_u32(struct p_log *log, const struct fs_parameter_spec *p,
struct fs_parameter *param, struct fs_parse_result *result)
{
diff --git a/include/linux/fs_parser.h b/include/linux/fs_parser.h
index 6cf713a7e6c6..1c940756300c 100644
--- a/include/linux/fs_parser.h
+++ b/include/linux/fs_parser.h
@@ -26,9 +26,10 @@ typedef int fs_param_type(struct p_log *,
/*
* The type of parameter expected.
*/
-fs_param_type fs_param_is_bool, fs_param_is_u32, fs_param_is_s32, fs_param_is_u64,
- fs_param_is_enum, fs_param_is_string, fs_param_is_blob, fs_param_is_blockdev,
- fs_param_is_path, fs_param_is_fd, fs_param_is_uid, fs_param_is_gid;
+fs_param_type fs_param_is_bool, fs_param_is_u16, fs_param_is_u32, fs_param_is_s32,
+ fs_param_is_u64, fs_param_is_enum, fs_param_is_string, fs_param_is_blob,
+ fs_param_is_blockdev, fs_param_is_path, fs_param_is_fd, fs_param_is_uid,
+ fs_param_is_gid;
/*
* Specification of the type of value a parameter wants.
@@ -55,6 +56,7 @@ struct fs_parse_result {
union {
bool boolean; /* For spec_bool */
int int_32; /* For spec_s32/spec_enum */
+ u16 uint_16; /* For spec_u16 */
unsigned int uint_32; /* For spec_u32{,_octal,_hex}/spec_enum */
u64 uint_64; /* For spec_u64 */
kuid_t uid;
@@ -119,6 +121,7 @@ static inline bool fs_validate_description(const char *name,
#define fsparam_flag_no(NAME, OPT) \
__fsparam(NULL, NAME, OPT, fs_param_neg_with_no, NULL)
#define fsparam_bool(NAME, OPT) __fsparam(fs_param_is_bool, NAME, OPT, 0, NULL)
+#define fsparam_u16(NAME, OPT) __fsparam(fs_param_is_u16, NAME, OPT, 0, NULL)
#define fsparam_u32(NAME, OPT) __fsparam(fs_param_is_u32, NAME, OPT, 0, NULL)
#define fsparam_u32oct(NAME, OPT) \
__fsparam(fs_param_is_u32, NAME, OPT, 0, (void *)8)
--
2.43.5
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH v7 2/3] fuse: add optional kernel-enforced timeout for requests
2024-10-07 18:42 [PATCH v7 0/3] fuse: add kernel-enforced request timeout option Joanne Koong
2024-10-07 18:42 ` [PATCH v7 1/3] fs_parser: add fsparam_u16 helper Joanne Koong
@ 2024-10-07 18:42 ` Joanne Koong
2024-10-09 8:14 ` Miklos Szeredi
2024-10-07 18:42 ` [PATCH v7 3/3] fuse: add default_request_timeout and max_request_timeout sysctls Joanne Koong
2024-10-08 20:58 ` [PATCH v7 0/3] fuse: add kernel-enforced request timeout option Joanne Koong
3 siblings, 1 reply; 9+ messages in thread
From: Joanne Koong @ 2024-10-07 18:42 UTC (permalink / raw)
To: miklos, linux-fsdevel
Cc: josef, bernd.schubert, jefflexu, laoar.shao, kernel-team
There are situations where fuse servers can become unresponsive or
stuck, for example if the server is deadlocked. Currently, there's no
good way to detect if a server is stuck and needs to be killed manually.
This commit adds an option for enforcing a timeout (in minutes) for
requests where if the timeout elapses without the server responding to
the request, the connection will be automatically aborted.
Please note that these timeouts are not 100% precise. The request may
take an extra FUSE_TIMEOUT_TIMER_FREQ seconds beyond the set max timeout
due to how it's internally implemented.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
---
fs/fuse/dev.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++-
fs/fuse/fuse_i.h | 45 ++++++++++++++++++++++++++++++++++
fs/fuse/inode.c | 22 +++++++++++++++++
3 files changed, 129 insertions(+), 1 deletion(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 1f64ae6d7a69..429c91c59e3a 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -45,14 +45,62 @@ static struct fuse_dev *fuse_get_dev(struct file *file)
return READ_ONCE(file->private_data);
}
+void fuse_check_timeout(struct timer_list *timer)
+{
+ struct fuse_conn *fc = container_of(timer, struct fuse_conn, timeout.timer);
+ struct fuse_req *req;
+ bool expired = false;
+
+ spin_lock(&fc->timeout.lock);
+ req = list_first_entry_or_null(&fc->timeout.list, struct fuse_req,
+ timer_entry);
+ if (req)
+ expired = jiffies > req->create_time + fc->timeout.req_timeout;
+ spin_unlock(&fc->timeout.lock);
+
+ /*
+ * Don't rearm the timer if the list was empty in case the filesystem
+ * is inactive. When the next request is sent, it'll rearm the timer.
+ */
+ if (!req)
+ return;
+
+ if (expired)
+ fuse_abort_conn(fc);
+ else
+ mod_timer(&fc->timeout.timer, jiffies + FUSE_TIMEOUT_TIMER_FREQ);
+}
+
+static void add_req_timeout_entry(struct fuse_conn *fc, struct fuse_req *req)
+{
+ spin_lock(&fc->timeout.lock);
+ if (!timer_pending(&fc->timeout.timer))
+ mod_timer(&fc->timeout.timer, jiffies + FUSE_TIMEOUT_TIMER_FREQ);
+ list_add_tail(&req->timer_entry, &fc->timeout.list);
+ spin_unlock(&fc->timeout.lock);
+}
+
+static void remove_req_timeout_entry(struct fuse_conn *fc, struct fuse_req *req)
+{
+ spin_lock(&fc->timeout.lock);
+ list_del(&req->timer_entry);
+ spin_unlock(&fc->timeout.lock);
+}
+
static void fuse_request_init(struct fuse_mount *fm, struct fuse_req *req)
{
+ struct fuse_conn *fc = fm->fc;
+
INIT_LIST_HEAD(&req->list);
INIT_LIST_HEAD(&req->intr_entry);
init_waitqueue_head(&req->waitq);
refcount_set(&req->count, 1);
__set_bit(FR_PENDING, &req->flags);
req->fm = fm;
+ if (fc->timeout.req_timeout) {
+ INIT_LIST_HEAD(&req->timer_entry);
+ req->create_time = jiffies;
+ }
}
static struct fuse_req *fuse_request_alloc(struct fuse_mount *fm, gfp_t flags)
@@ -359,6 +407,9 @@ void fuse_request_end(struct fuse_req *req)
if (test_and_set_bit(FR_FINISHED, &req->flags))
goto put_request;
+ if (fc->timeout.req_timeout)
+ remove_req_timeout_entry(fc, req);
+
trace_fuse_request_end(req);
/*
* test_and_set_bit() implies smp_mb() between bit
@@ -450,6 +501,8 @@ static void request_wait_answer(struct fuse_req *req)
if (test_bit(FR_PENDING, &req->flags)) {
list_del(&req->list);
spin_unlock(&fiq->lock);
+ if (fc->timeout.req_timeout)
+ remove_req_timeout_entry(fc, req);
__fuse_put_request(req);
req->out.h.error = -EINTR;
return;
@@ -466,13 +519,16 @@ static void request_wait_answer(struct fuse_req *req)
static void __fuse_request_send(struct fuse_req *req)
{
- struct fuse_iqueue *fiq = &req->fm->fc->iq;
+ struct fuse_conn *fc = req->fm->fc;
+ struct fuse_iqueue *fiq = &fc->iq;
BUG_ON(test_bit(FR_BACKGROUND, &req->flags));
/* acquire extra reference, since request is still needed after
fuse_request_end() */
__fuse_get_request(req);
+ if (fc->timeout.req_timeout)
+ add_req_timeout_entry(fc, req);
fuse_send_one(fiq, req);
request_wait_answer(req);
@@ -598,6 +654,8 @@ static bool fuse_request_queue_background(struct fuse_req *req)
if (fc->num_background == fc->max_background)
fc->blocked = 1;
list_add_tail(&req->list, &fc->bg_queue);
+ if (fc->timeout.req_timeout)
+ add_req_timeout_entry(fc, req);
flush_bg_queue(fc);
queued = true;
}
@@ -2296,6 +2354,9 @@ void fuse_abort_conn(struct fuse_conn *fc)
spin_unlock(&fc->lock);
end_requests(&to_end);
+
+ if (fc->timeout.req_timeout)
+ timer_delete(&fc->timeout.timer);
} else {
spin_unlock(&fc->lock);
}
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index 7ff00bae4a84..4c3998c28519 100644
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -435,6 +435,16 @@ struct fuse_req {
/** fuse_mount this request belongs to */
struct fuse_mount *fm;
+
+ /*
+ * These fields are only used if the connection enforces request
+ * timeouts.
+ *
+ * timer_entry is the entry on the fuse connection's timeout list.
+ * create_time (in jiffies) tracks when the request was created.
+ */
+ struct list_head timer_entry;
+ unsigned long create_time;
};
struct fuse_iqueue;
@@ -525,6 +535,33 @@ struct fuse_pqueue {
struct list_head io;
};
+/* Frequency (in seconds) of request timeout checks, if opted into */
+#define FUSE_TIMEOUT_TIMER_FREQ 60 * HZ
+
+/*
+ * If the connection enforces request timeouts, then all requests get
+ * added to the list when created and removed from the list when fulfilled by
+ * the server.
+ *
+ * The timer is triggered every FUSE_TIMEOUT_TIMER_FREQ seconds. It will
+ * check the head of the list for whether that request's start_time
+ * exceeds the timeout. If so, then the connection will be aborted.
+ *
+ * In the worst case, this guarantees that all requests will take
+ * the specified timeout + FUSE_TIMEOUT_TIMER_FREQ time to fulfill.
+ */
+struct fuse_timeout {
+ struct timer_list timer;
+
+ /* Request timeout (in jiffies). 0 = no timeout */
+ unsigned long req_timeout;
+
+ spinlock_t lock;
+
+ /* List of all requests that haven't been completed yet */
+ struct list_head list;
+};
+
/**
* Fuse device instance
*/
@@ -571,6 +608,8 @@ struct fuse_fs_context {
enum fuse_dax_mode dax_mode;
unsigned int max_read;
unsigned int blksize;
+ /* Request timeout (in minutes). 0 = no timeout (infinite wait) */
+ unsigned int req_timeout;
const char *subtype;
/* DAX device, may be NULL */
@@ -914,6 +953,9 @@ struct fuse_conn {
/** IDR for backing files ids */
struct idr backing_files_map;
#endif
+
+ /** Only used if the connection enforces request timeouts */
+ struct fuse_timeout timeout;
};
/*
@@ -1175,6 +1217,9 @@ void fuse_request_end(struct fuse_req *req);
void fuse_abort_conn(struct fuse_conn *fc);
void fuse_wait_aborted(struct fuse_conn *fc);
+/* Check if any requests timed out */
+void fuse_check_timeout(struct timer_list *timer);
+
/**
* Invalidate inode attributes
*/
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index f1779ff3f8d1..e5c7a214a222 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -735,6 +735,7 @@ enum {
OPT_ALLOW_OTHER,
OPT_MAX_READ,
OPT_BLKSIZE,
+ OPT_REQUEST_TIMEOUT,
OPT_ERR
};
@@ -749,6 +750,7 @@ static const struct fs_parameter_spec fuse_fs_parameters[] = {
fsparam_u32 ("max_read", OPT_MAX_READ),
fsparam_u32 ("blksize", OPT_BLKSIZE),
fsparam_string ("subtype", OPT_SUBTYPE),
+ fsparam_u16 ("request_timeout", OPT_REQUEST_TIMEOUT),
{}
};
@@ -844,6 +846,10 @@ static int fuse_parse_param(struct fs_context *fsc, struct fs_parameter *param)
ctx->blksize = result.uint_32;
break;
+ case OPT_REQUEST_TIMEOUT:
+ ctx->req_timeout = result.uint_16;
+ break;
+
default:
return -EINVAL;
}
@@ -973,6 +979,8 @@ void fuse_conn_put(struct fuse_conn *fc)
if (IS_ENABLED(CONFIG_FUSE_DAX))
fuse_dax_conn_free(fc);
+ if (fc->timeout.req_timeout)
+ timer_delete_sync(&fc->timeout.timer);
if (fiq->ops->release)
fiq->ops->release(fiq);
put_pid_ns(fc->pid_ns);
@@ -1691,6 +1699,19 @@ int fuse_init_fs_context_submount(struct fs_context *fsc)
}
EXPORT_SYMBOL_GPL(fuse_init_fs_context_submount);
+static void fuse_init_fc_timeout(struct fuse_conn *fc, struct fuse_fs_context *ctx)
+{
+ if (ctx->req_timeout) {
+ if (check_mul_overflow(ctx->req_timeout * 60, HZ, &fc->timeout.req_timeout))
+ fc->timeout.req_timeout = U32_MAX;
+ INIT_LIST_HEAD(&fc->timeout.list);
+ spin_lock_init(&fc->timeout.lock);
+ timer_setup(&fc->timeout.timer, fuse_check_timeout, 0);
+ } else {
+ fc->timeout.req_timeout = 0;
+ }
+}
+
int fuse_fill_super_common(struct super_block *sb, struct fuse_fs_context *ctx)
{
struct fuse_dev *fud = NULL;
@@ -1753,6 +1774,7 @@ int fuse_fill_super_common(struct super_block *sb, struct fuse_fs_context *ctx)
fc->destroy = ctx->destroy;
fc->no_control = ctx->no_control;
fc->no_force_umount = ctx->no_force_umount;
+ fuse_init_fc_timeout(fc, ctx);
err = -ENOMEM;
root = fuse_get_root_inode(sb, ctx->rootmode);
--
2.43.5
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v7 2/3] fuse: add optional kernel-enforced timeout for requests
2024-10-07 18:42 ` [PATCH v7 2/3] fuse: add optional kernel-enforced timeout for requests Joanne Koong
@ 2024-10-09 8:14 ` Miklos Szeredi
2024-10-10 0:44 ` Joanne Koong
0 siblings, 1 reply; 9+ messages in thread
From: Miklos Szeredi @ 2024-10-09 8:14 UTC (permalink / raw)
To: Joanne Koong
Cc: linux-fsdevel, josef, bernd.schubert, jefflexu, laoar.shao,
kernel-team
On Mon, 7 Oct 2024 at 20:43, Joanne Koong <joannelkoong@gmail.com> wrote:
>
> There are situations where fuse servers can become unresponsive or
> stuck, for example if the server is deadlocked. Currently, there's no
> good way to detect if a server is stuck and needs to be killed manually.
>
> This commit adds an option for enforcing a timeout (in minutes) for
> requests where if the timeout elapses without the server responding to
> the request, the connection will be automatically aborted.
>
> Please note that these timeouts are not 100% precise. The request may
> take an extra FUSE_TIMEOUT_TIMER_FREQ seconds beyond the set max timeout
> due to how it's internally implemented.
One thing I worry about is adding more roadblocks on the way to making
request queuing more scalable.
Currently there's fc->num_waiting that's touched on all requests and
bg_queue/bg_lock that are touched on background requests. We should
be trying to fix these bottlenecks instead of adding more.
Can't we use the existing lists to scan requests?
It's more complex, obviously, but at least it doesn't introduce yet
another per-fc list to worry about.
Thanks,
Miklos
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v7 2/3] fuse: add optional kernel-enforced timeout for requests
2024-10-09 8:14 ` Miklos Szeredi
@ 2024-10-10 0:44 ` Joanne Koong
2024-10-10 8:21 ` Miklos Szeredi
0 siblings, 1 reply; 9+ messages in thread
From: Joanne Koong @ 2024-10-10 0:44 UTC (permalink / raw)
To: Miklos Szeredi
Cc: linux-fsdevel, josef, bernd.schubert, jefflexu, laoar.shao,
kernel-team
On Wed, Oct 9, 2024 at 1:14 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Mon, 7 Oct 2024 at 20:43, Joanne Koong <joannelkoong@gmail.com> wrote:
> >
> > There are situations where fuse servers can become unresponsive or
> > stuck, for example if the server is deadlocked. Currently, there's no
> > good way to detect if a server is stuck and needs to be killed manually.
> >
> > This commit adds an option for enforcing a timeout (in minutes) for
> > requests where if the timeout elapses without the server responding to
> > the request, the connection will be automatically aborted.
> >
> > Please note that these timeouts are not 100% precise. The request may
> > take an extra FUSE_TIMEOUT_TIMER_FREQ seconds beyond the set max timeout
> > due to how it's internally implemented.
>
> One thing I worry about is adding more roadblocks on the way to making
> request queuing more scalable.
>
> Currently there's fc->num_waiting that's touched on all requests and
> bg_queue/bg_lock that are touched on background requests. We should
> be trying to fix these bottlenecks instead of adding more.
>
> Can't we use the existing lists to scan requests?
Hi Miklos,
The existing lists we have are:
* fiq pending list (per connection)
* fpq io list and fpq processing (for its associated hash) list (per fuse dev)
* bg queue (per connection)
If we wanted to reuse existing lists, we could do this in the timeout handler:
* grab the fiq lock, check the head entry of the pending list, release the lock
* grab the bg lock, check the head entry of the bg_queue, release the lock
* for each connection's fuse dev, grab the fpq lock, check the head
entry of the fpq->io list, iterate through the fpq->processing's lists
for 256 hashes and check against the head entry, release the lock
but some requests could slip through for the following cases:
-- resend:
* Request is on the resend's to_queue list when the timeout handler
check runs, in which case if that request is expired we won't get to
that until the next time the timeout handler kicks in
* A re-sent request may be moved to the head of the fiq->pending list,
but have a creation time newer than other entries on the fiq->pending
list , in which case we would not time out and abort the connection
when we should be doing so
-- transitioning between lists
* A request that is between lists (eg fpq->io and fpq->processing)
could be missed when the timeout handler check runs (but will probably
be caught the next time the timeout handler kicks in. We could also
modify the logic in dev_do_read to use list_move to avoid this case).
I think it's fine for these edge cases to slip through since most of
them will be caught eventually by the subsequent timeout handler runs,
but I was more worried about the increased lock contention while
iterating through all hashes of the fpq->processing list. But I think
for that we could just increase the timeout frequency to run less
frequently (eg once every 5 minutes instead of once every minute)
Do you think something like this sounds more reasonable?
Alternatively, I also still like the idea of something looser with
just periodically (according to whatever specified timeout) checking
if any requests are being serviced at all when fc->num-waiting is
non-zero. However, this would only protect against fully deadlocked
servers and miss malicious ones or half-deadlocked ones (eg
multithreaded fuse servers where only some threads are deadlocked).
Thanks,
Joanne
>
> It's more complex, obviously, but at least it doesn't introduce yet
> another per-fc list to worry about.
>
> Thanks,
> Miklos
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v7 2/3] fuse: add optional kernel-enforced timeout for requests
2024-10-10 0:44 ` Joanne Koong
@ 2024-10-10 8:21 ` Miklos Szeredi
2024-10-10 23:08 ` Joanne Koong
0 siblings, 1 reply; 9+ messages in thread
From: Miklos Szeredi @ 2024-10-10 8:21 UTC (permalink / raw)
To: Joanne Koong
Cc: linux-fsdevel, josef, bernd.schubert, jefflexu, laoar.shao,
kernel-team
On Thu, 10 Oct 2024 at 02:45, Joanne Koong <joannelkoong@gmail.com> wrote:
> I think it's fine for these edge cases to slip through since most of
> them will be caught eventually by the subsequent timeout handler runs,
> but I was more worried about the increased lock contention while
> iterating through all hashes of the fpq->processing list. But I think
> for that we could just increase the timeout frequency to run less
> frequently (eg once every 5 minutes instead of once every minute)
Yeah, edge cases shouldn't matter. I think even 1/s frequency
wouldn't be too bad, this is just a quick scan of a (hopefully) not
too long list.
BTW, the cumulative lock contention would be exactly the same with the
separate timeout list, I wouldn't worry too much about it.
> Alternatively, I also still like the idea of something looser with
> just periodically (according to whatever specified timeout) checking
> if any requests are being serviced at all when fc->num-waiting is
> non-zero. However, this would only protect against fully deadlocked
> servers and miss malicious ones or half-deadlocked ones (eg
> multithreaded fuse servers where only some threads are deadlocked).
I don't have a preference. Whichever is simpler to implement.
Thanks,
Miklos
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v7 2/3] fuse: add optional kernel-enforced timeout for requests
2024-10-10 8:21 ` Miklos Szeredi
@ 2024-10-10 23:08 ` Joanne Koong
0 siblings, 0 replies; 9+ messages in thread
From: Joanne Koong @ 2024-10-10 23:08 UTC (permalink / raw)
To: Miklos Szeredi
Cc: linux-fsdevel, josef, bernd.schubert, jefflexu, laoar.shao,
kernel-team
On Thu, Oct 10, 2024 at 1:21 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Thu, 10 Oct 2024 at 02:45, Joanne Koong <joannelkoong@gmail.com> wrote:
> > I think it's fine for these edge cases to slip through since most of
> > them will be caught eventually by the subsequent timeout handler runs,
> > but I was more worried about the increased lock contention while
> > iterating through all hashes of the fpq->processing list. But I think
> > for that we could just increase the timeout frequency to run less
> > frequently (eg once every 5 minutes instead of once every minute)
>
> Yeah, edge cases shouldn't matter. I think even 1/s frequency
> wouldn't be too bad, this is just a quick scan of a (hopefully) not
> too long list.
>
> BTW, the cumulative lock contention would be exactly the same with the
> separate timeout list, I wouldn't worry too much about it.
>
> > Alternatively, I also still like the idea of something looser with
> > just periodically (according to whatever specified timeout) checking
> > if any requests are being serviced at all when fc->num-waiting is
> > non-zero. However, this would only protect against fully deadlocked
> > servers and miss malicious ones or half-deadlocked ones (eg
> > multithreaded fuse servers where only some threads are deadlocked).
>
> I don't have a preference. Whichever is simpler to implement.
>
Sounds great, thanks for the feedback. I'll submit v8 with these new
changes of reusing the existing lists.
Thanks,
Joanne
> Thanks,
> Miklos
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v7 3/3] fuse: add default_request_timeout and max_request_timeout sysctls
2024-10-07 18:42 [PATCH v7 0/3] fuse: add kernel-enforced request timeout option Joanne Koong
2024-10-07 18:42 ` [PATCH v7 1/3] fs_parser: add fsparam_u16 helper Joanne Koong
2024-10-07 18:42 ` [PATCH v7 2/3] fuse: add optional kernel-enforced timeout for requests Joanne Koong
@ 2024-10-07 18:42 ` Joanne Koong
2024-10-08 20:58 ` [PATCH v7 0/3] fuse: add kernel-enforced request timeout option Joanne Koong
3 siblings, 0 replies; 9+ messages in thread
From: Joanne Koong @ 2024-10-07 18:42 UTC (permalink / raw)
To: miklos, linux-fsdevel
Cc: josef, bernd.schubert, jefflexu, laoar.shao, kernel-team
Introduce two new sysctls, "default_request_timeout" and
"max_request_timeout". These control how long (in minutes) a server can
take to reply to a request. If the server does not reply by the timeout,
then the connection will be aborted.
"default_request_timeout" sets the default timeout if no timeout is
specified by the fuse server on mount. 0 (default) indicates no default
timeout should be enforced. If the server did specify a timeout, then
default_request_timeout will be ignored.
"max_request_timeout" sets the max amount of time the server may take to
reply to a request. 0 (default) indicates no maximum timeout. If
max_request_timeout is set and the fuse server attempts to set a
timeout greater than max_request_timeout, the system will use
max_request_timeout as the timeout. Similarly, if default_request_timeout
is greater than max_request_timeout, the system will use
max_request_timeout as the timeout. If the server does not request a
timeout and default_request_timeout is set to 0 but max_request_timeout
is set, then the timeout will be max_request_timeout.
Please note that these timeouts are not 100% precise. The request may
take an extra FUSE_TIMEOUT_TIMER_FREQ seconds beyond the set max timeout
due to how it's internally implemented.
$ sysctl -a | grep fuse.default_request_timeout
fs.fuse.default_request_timeout = 0
$ echo 65536 | sudo tee /proc/sys/fs/fuse/default_request_timeout
tee: /proc/sys/fs/fuse/default_request_timeout: Invalid argument
$ echo 65535 | sudo tee /proc/sys/fs/fuse/default_request_timeout
65535
$ sysctl -a | grep fuse.default_request_timeout
fs.fuse.default_request_timeout = 65535
$ echo 0 | sudo tee /proc/sys/fs/fuse/default_request_timeout
0
$ sysctl -a | grep fuse.default_request_timeout
fs.fuse.default_request_timeout = 0
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
---
Documentation/admin-guide/sysctl/fs.rst | 27 +++++++++++++++++++++++++
fs/fuse/fuse_i.h | 10 +++++++++
fs/fuse/inode.c | 16 +++++++++++++--
fs/fuse/sysctl.c | 20 ++++++++++++++++++
4 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst
index fa25d7e718b3..790a34291467 100644
--- a/Documentation/admin-guide/sysctl/fs.rst
+++ b/Documentation/admin-guide/sysctl/fs.rst
@@ -342,3 +342,30 @@ filesystems:
``/proc/sys/fs/fuse/max_pages_limit`` is a read/write file for
setting/getting the maximum number of pages that can be used for servicing
requests in FUSE.
+
+``/proc/sys/fs/fuse/default_request_timeout`` is a read/write file for
+setting/getting the default timeout (in minutes) for a fuse server to
+reply to a kernel-issued request in the event where the server did not
+specify a timeout at mount. If the server set a timeout,
+then default_request_timeout will be ignored. The default
+"default_request_timeout" is set to 0. 0 indicates a no-op (eg
+requests will not have a default request timeout set if no timeout was
+specified by the server).
+
+``/proc/sys/fs/fuse/max_request_timeout`` is a read/write file for
+setting/getting the maximum timeout (in minutes) for a fuse server to
+reply to a kernel-issued request. A value greater than 0 automatically opts
+the server into a timeout that will be at most "max_request_timeout", even if
+the server did not specify a timeout and default_request_timeout is set to 0.
+If max_request_timeout is greater than 0 and the server set a timeout greater
+than max_request_timeout or default_request_timeout is set to a value greater
+than max_request_timeout, the system will use max_request_timeout as the
+timeout. 0 indicates a no-op (eg requests will not have an upper bound on the
+timeout and if the server did not request a timeout and default_request_timeout
+was not set, there will be no timeout).
+
+Please note that for the timeout options, if the server does not respond to
+the request by the time the timeout elapses, then the connection to the fuse
+server will be aborted. Please also note that the timeouts are not 100%
+precise (eg you may set 10 minutes but the timeout may kick in after 11
+minutes).
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index 4c3998c28519..b9f75e23ca17 100644
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -46,6 +46,16 @@
/** Maximum of max_pages received in init_out */
extern unsigned int fuse_max_pages_limit;
+/*
+ * Default timeout (in minutes) for the server to reply to a request
+ * before the connection is aborted, if no timeout was specified on mount.
+ */
+extern unsigned int fuse_default_req_timeout;
+/*
+ * Max timeout (in minutes) for the server to reply to a request before
+ * the connection is aborted.
+ */
+extern unsigned int fuse_max_req_timeout;
/** List of active connections */
extern struct list_head fuse_conn_list;
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index e5c7a214a222..40656f60d7ac 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -36,6 +36,9 @@ DEFINE_MUTEX(fuse_mutex);
static int set_global_limit(const char *val, const struct kernel_param *kp);
unsigned int fuse_max_pages_limit = 256;
+/* default is no timeout */
+unsigned int fuse_default_req_timeout = 0;
+unsigned int fuse_max_req_timeout = 0;
unsigned max_user_bgreq;
module_param_call(max_user_bgreq, set_global_limit, param_get_uint,
@@ -1701,8 +1704,17 @@ EXPORT_SYMBOL_GPL(fuse_init_fs_context_submount);
static void fuse_init_fc_timeout(struct fuse_conn *fc, struct fuse_fs_context *ctx)
{
- if (ctx->req_timeout) {
- if (check_mul_overflow(ctx->req_timeout * 60, HZ, &fc->timeout.req_timeout))
+ unsigned int timeout = ctx->req_timeout ?: fuse_default_req_timeout;
+
+ if (fuse_max_req_timeout) {
+ if (!timeout)
+ timeout = fuse_max_req_timeout;
+ else
+ timeout = min(timeout, fuse_max_req_timeout);
+ }
+
+ if (timeout) {
+ if (check_mul_overflow(timeout * 60, HZ, &fc->timeout.req_timeout))
fc->timeout.req_timeout = U32_MAX;
INIT_LIST_HEAD(&fc->timeout.list);
spin_lock_init(&fc->timeout.lock);
diff --git a/fs/fuse/sysctl.c b/fs/fuse/sysctl.c
index b272bb333005..e70b5269c16d 100644
--- a/fs/fuse/sysctl.c
+++ b/fs/fuse/sysctl.c
@@ -13,6 +13,8 @@ static struct ctl_table_header *fuse_table_header;
/* Bound by fuse_init_out max_pages, which is a u16 */
static unsigned int sysctl_fuse_max_pages_limit = 65535;
+static unsigned int sysctl_fuse_max_req_timeout_limit = U16_MAX;
+
static struct ctl_table fuse_sysctl_table[] = {
{
.procname = "max_pages_limit",
@@ -23,6 +25,24 @@ static struct ctl_table fuse_sysctl_table[] = {
.extra1 = SYSCTL_ONE,
.extra2 = &sysctl_fuse_max_pages_limit,
},
+ {
+ .procname = "default_request_timeout",
+ .data = &fuse_default_req_timeout,
+ .maxlen = sizeof(fuse_default_req_timeout),
+ .mode = 0644,
+ .proc_handler = proc_douintvec_minmax,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = &sysctl_fuse_max_req_timeout_limit,
+ },
+ {
+ .procname = "max_request_timeout",
+ .data = &fuse_max_req_timeout,
+ .maxlen = sizeof(fuse_max_req_timeout),
+ .mode = 0644,
+ .proc_handler = proc_douintvec_minmax,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = &sysctl_fuse_max_req_timeout_limit,
+ },
};
int fuse_sysctl_register(void)
--
2.43.5
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v7 0/3] fuse: add kernel-enforced request timeout option
2024-10-07 18:42 [PATCH v7 0/3] fuse: add kernel-enforced request timeout option Joanne Koong
` (2 preceding siblings ...)
2024-10-07 18:42 ` [PATCH v7 3/3] fuse: add default_request_timeout and max_request_timeout sysctls Joanne Koong
@ 2024-10-08 20:58 ` Joanne Koong
3 siblings, 0 replies; 9+ messages in thread
From: Joanne Koong @ 2024-10-08 20:58 UTC (permalink / raw)
To: miklos, linux-fsdevel
Cc: josef, bernd.schubert, jefflexu, laoar.shao, kernel-team
On Mon, Oct 7, 2024 at 11:43 AM Joanne Koong <joannelkoong@gmail.com> 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 where if the server does not reply to a
> 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 systems running fuse servers will not be affected unless they
> explicitly opt into the timeout.
>
> v6:
> https://lore.kernel.org/linux-fsdevel/20240830162649.3849586-1-joannelkoong@gmail.com/
> Changes from v6 -> v7:
> - Make timer per-connection instead of per-request (Miklos)
> - Make default granularity of time minutes instead of seconds
> - Removed the reviewed-bys since the interface of this has changed (now
> minutes, instead of seconds)
>
> v5:
> https://lore.kernel.org/linux-fsdevel/20240826203234.4079338-1-joannelkoong@gmail.com/
> Changes from v5 -> v6:
> - Gate sysctl.o behind CONFIG_SYSCTL in makefile (kernel test robot)
> - Reword/clarify last sentence in cover letter (Miklos)
>
> v4:
> https://lore.kernel.org/linux-fsdevel/20240813232241.2369855-1-joannelkoong@gmail.com/
> Changes from v4 -> v5:
> - Change timeout behavior from aborting request to aborting connection
> (Miklos)
> - Clarify wording for sysctl documentation (Jingbo)
>
> v3:
> https://lore.kernel.org/linux-fsdevel/20240808190110.3188039-1-joannelkoong@gmail.com/
> Changes from v3 -> v4:
> - Fix wording on some comments to make it more clear
> - Use simpler logic for timer (eg remove extra if checks, use mod timer API)
> (Josef)
> - Sanity-check should be on FR_FINISHING not FR_FINISHED (Jingbo)
> - Fix comment for "processing queue", add req->fpq = NULL safeguard (Bernd)
>
> v2:
> https://lore.kernel.org/linux-fsdevel/20240730002348.3431931-1-joannelkoong@gmail.com/
> Changes from v2 -> v3:
> - Disarm / rearm timer in dev_do_read to handle race conditions (Bernrd)
> - Disarm timer in error handling for fatal interrupt (Yafang)
> - Clean up do_fuse_request_end (Jingbo)
> - Add timer for notify retrieve requests
> - Fix kernel test robot errors for #define no-op functions
>
> v1:
> https://lore.kernel.org/linux-fsdevel/20240717213458.1613347-1-joannelkoong@gmail.com/
> Changes from v1 -> v2:
> - Add timeout for background requests
> - Handle resend race condition
> - Add sysctls
>
> Joanne Koong (3):
> fs_parser: add fsparam_u16 helper
> fuse: add optional kernel-enforced timeout for requests
> fuse: add default_request_timeout and max_request_timeout sysctls
>
> Documentation/admin-guide/sysctl/fs.rst | 27 +++++++++++
> fs/fs_parser.c | 14 ++++++
> fs/fuse/dev.c | 63 ++++++++++++++++++++++++-
> fs/fuse/fuse_i.h | 55 +++++++++++++++++++++
> fs/fuse/inode.c | 34 +++++++++++++
> fs/fuse/sysctl.c | 20 ++++++++
> include/linux/fs_parser.h | 9 ++--
> 7 files changed, 218 insertions(+), 4 deletions(-)
>
> --
> 2.43.5
>
These are the benchmark numbers I am seeing on my machine:
--- Machine info ---
Architecture: x86_64
CPU(s): 36
On-line CPU(s) list: 0-35
Model name: Intel(R) Xeon(R) D-2191A CPU @ 1.60GHz
BIOS Model name: Intel(R) Xeon(R) D-2191A CPU @ 1.60GHz
CPU family: 6
Model: 85
Thread(s) per core: 2
Core(s) per socket: 18
Socket(s): 1
Stepping: 4
Frequency boost: disabled
CPU(s) scaling MHz: 100%
CPU max MHz: 1601.0000
CPU min MHz: 800.0000
--- Setting up the testing environment ---
sudo mount -t tmpfs -o size=10G tmpfs ~/tmp_mount
Mount libfuse server for tests:
for test a) Non-passthrough writes -
./libfuse/build/example/passthrough_ll -o max_threads=4 -o
source=/root/tmp_mount /root/fuse_mount
for test b) Passthrough writes -
./libfuse/build/example/passthrough_hp --num-threads=4
/root/tmp_mount. /root/fuse_mount
Test using fio:
fio --name=seqwrite --ioengine=sync --rw=write --bs=1k --size=1G
--numjobs=4 --fallocate=none --ramp_time=30 --group_reporting=1
--directory=/root/fuse_mount
Enable timeouts by running 'echo 500 | sudo tee
/proc/sys/fs/fuse/default_request_timeout' before mounting fuse server
Disable timeouts by running 'echo 0 | sudo tee
/proc/sys/fs/fuse/default_request_timeout' before mounting fuse server
Discarded outliers
--- Tests ---
a) Non-passthrough sequential writes
./libfuse/build/example/passthrough_ll -o max_threads=4 -o
source=/root/tmp_mount /root/fuse_mount
--- Baseline (no timeouts) ---
Ran this on origin/for-next
Saw around ~273 MiB/s
WRITE: bw=277MiB/s (291MB/s), 277MiB/s-277MiB/s (291MB/s-291MB/s),
io=4096MiB (4295MB), run=14761-14761msec
WRITE: bw=271MiB/s (285MB/s), 271MiB/s-271MiB/s (285MB/s-285MB/s),
io=4096MiB (4295MB), run=15091-15091msec
WRITE: bw=274MiB/s (287MB/s), 274MiB/s-274MiB/s (287MB/s-287MB/s),
io=4096MiB (4295MB), run=14949-14949msec
WRITE: bw=277MiB/s (290MB/s), 277MiB/s-277MiB/s (290MB/s-290MB/s),
io=4096MiB (4295MB), run=14801-14801msec
WRITE: bw=274MiB/s (288MB/s), 274MiB/s-274MiB/s (288MB/s-288MB/s),
io=4096MiB (4295MB), run=14939-14939msec
WRITE: bw=272MiB/s (285MB/s), 272MiB/s-272MiB/s (285MB/s-285MB/s),
io=4096MiB (4295MB), run=15060-15060msec
WRITE: bw=269MiB/s (282MB/s), 269MiB/s-269MiB/s (282MB/s-282MB/s),
io=4096MiB (4295MB), run=15254-15254msec
WRITE: bw=272MiB/s (285MB/s), 272MiB/s-272MiB/s (285MB/s-285MB/s),
io=4096MiB (4295MB), run=15055-15055msec
WRITE: bw=275MiB/s (288MB/s), 275MiB/s-275MiB/s (288MB/s-288MB/s),
io=4096MiB (4295MB), run=14893-14893msec
WRITE: bw=270MiB/s (283MB/s), 270MiB/s-270MiB/s (283MB/s-283MB/s),
io=4096MiB (4295MB), run=15176-15176msec
--- Request timeouts with periodic timer (approach from this patchset) ---
Saw around ~271MiB/s
WRITE: bw=265MiB/s (278MB/s), 265MiB/s-265MiB/s (278MB/s-278MB/s),
io=4096MiB (4295MB), run=15454-15454msec
WRITE: bw=268MiB/s (281MB/s), 268MiB/s-268MiB/s (281MB/s-281MB/s),
io=4096MiB (4295MB), run=15262-15262msec
WRITE: bw=271MiB/s (284MB/s), 271MiB/s-271MiB/s (284MB/s-284MB/s),
io=4096MiB (4295MB), run=15113-15113msec
WRITE: bw=268MiB/s (281MB/s), 268MiB/s-268MiB/s (281MB/s-281MB/s),
io=4096MiB (4295MB), run=15301-15301msec
WRITE: bw=274MiB/s (287MB/s), 274MiB/s-274MiB/s (287MB/s-287MB/s),
io=4096MiB (4295MB), run=14965-14965msec
WRITE: bw=268MiB/s (281MB/s), 268MiB/s-268MiB/s (281MB/s-281MB/s),
io=4096MiB (4295MB), run=15277-15277msec
WRITE: bw=276MiB/s (290MB/s), 276MiB/s-276MiB/s (290MB/s-290MB/s),
io=4096MiB (4295MB), run=14828-14828msec
WRITE: bw=272MiB/s (285MB/s), 272MiB/s-272MiB/s (285MB/s-285MB/s),
io=4096MiB (4295MB), run=15069-15069msec
WRITE: bw=273MiB/s (287MB/s), 273MiB/s-273MiB/s (287MB/s-287MB/s),
io=4096MiB (4295MB), run=14987-14987msec
WRITE: bw=279MiB/s (293MB/s), 279MiB/s-279MiB/s (293MB/s-293MB/s),
io=4096MiB (4295MB), run=14662-14662msec
WRITE: bw=272MiB/s (285MB/s), 272MiB/s-272MiB/s (285MB/s-285MB/s),
io=4096MiB (4295MB), run=15071-15071msec
--- Request timeouts with one timer per request (approach from v6 [1]) ---
Saw around ~263MiB/s
WRITE: bw=262MiB/s (275MB/s), 262MiB/s-262MiB/s (275MB/s-275MB/s),
io=4096MiB (4295MB), run=15620-15620msec
WRITE: bw=262MiB/s (275MB/s), 262MiB/s-262MiB/s (275MB/s-275MB/s),
io=4096MiB (4295MB), run=15614-15614msec
WRITE: bw=256MiB/s (269MB/s), 256MiB/s-256MiB/s (269MB/s-269MB/s),
io=4096MiB (4295MB), run=15995-15995msec
WRITE: bw=264MiB/s (277MB/s), 264MiB/s-264MiB/s (277MB/s-277MB/s),
io=4096MiB (4295MB), run=15504-15504msec
WRITE: bw=260MiB/s (273MB/s), 260MiB/s-260MiB/s (273MB/s-273MB/s),
io=4096MiB (4295MB), run=15749-15749msec
WRITE: bw=267MiB/s (280MB/s), 267MiB/s-267MiB/s (280MB/s-280MB/s),
io=4096MiB (4295MB), run=15354-15354msec
WRITE: bw=266MiB/s (279MB/s), 266MiB/s-266MiB/s (279MB/s-279MB/s),
io=4096MiB (4295MB), run=15409-15409msec
WRITE: bw=265MiB/s (277MB/s), 265MiB/s-265MiB/s (277MB/s-277MB/s),
io=4096MiB (4295MB), run=15480-15480msec
WRITE: bw=268MiB/s (281MB/s), 268MiB/s-268MiB/s (281MB/s-281MB/s),
io=4096MiB (4295MB), run=15283-15283msec
WRITE: bw=267MiB/s (280MB/s), 267MiB/s-267MiB/s (280MB/s-280MB/s),
io=4096MiB (4295MB), run=15332-15332msec
b) Passthrough sequential writes
./libfuse/build/example/passthrough_hp --num-threads=4
/root/tmp_mount. /root/fuse_mount
--- Baseline (no timeouts) ---
Ran this on origin/for-next
Saw around ~245 MiB/s
WRITE: bw=246MiB/s (258MB/s), 246MiB/s-246MiB/s (258MB/s-258MB/s),
io=4096MiB (4295MB), run=16676-16676msec
WRITE: bw=248MiB/s (260MB/s), 248MiB/s-248MiB/s (260MB/s-260MB/s),
io=4096MiB (4295MB), run=16508-16508msec
WRITE: bw=246MiB/s (258MB/s), 246MiB/s-246MiB/s (258MB/s-258MB/s),
io=4096MiB (4295MB), run=16636-16636msec
WRITE: bw=246MiB/s (258MB/s), 246MiB/s-246MiB/s (258MB/s-258MB/s),
io=4096MiB (4295MB), run=16654-16654msec
WRITE: bw=242MiB/s (253MB/s), 242MiB/s-242MiB/s (253MB/s-253MB/s),
io=4096MiB (4295MB), run=16957-16957msec
WRITE: bw=249MiB/s (261MB/s), 249MiB/s-249MiB/s (261MB/s-261MB/s),
io=4096MiB (4295MB), run=16449-16449msec
WRITE: bw=245MiB/s (257MB/s), 245MiB/s-245MiB/s (257MB/s-257MB/s),
io=4096MiB (4295MB), run=16699-16699msc
WRITE: bw=241MiB/s (253MB/s), 241MiB/s-241MiB/s (253MB/s-253MB/s),
io=4096MiB (4295MB), run=16981-16981msec
WRITE: bw=244MiB/s (256MB/s), 244MiB/s-244MiB/s (256MB/s-256MB/s),
io=4096MiB (4295MB), run=16792-16792msec
WRITE: bw=246MiB/s (258MB/s), 246MiB/s-246MiB/s (258MB/s-258MB/s),
io=4096MiB (4295MB), run=16665-16665msec
--- Request timeouts with periodic timer (approach from this patchset) ---
Saw around ~237 MiB/s
WRITE: bw=237MiB/s (248MB/s), 237MiB/s-237MiB/s (248MB/s-248MB/s),
io=4096MiB (4295MB), run=17295-17295msec
WRITE: bw=236MiB/s (247MB/s), 236MiB/s-236MiB/s (247MB/s-247MB/s),
io=4096MiB (4295MB), run=17357-17357msec
WRITE: bw=240MiB/s (251MB/s), 240MiB/s-240MiB/s (251MB/s-251MB/s),
io=4096MiB (4295MB), run=17096-17096msec
WRITE: bw=238MiB/s (249MB/s), 238MiB/s-238MiB/s (249MB/s-249MB/s),
io=4096MiB (4295MB), run=17245-17245msec
WRITE: bw=236MiB/s (247MB/s), 236MiB/s-236MiB/s (247MB/s-247MB/s),
io=4096MiB (4295MB), run=17365-17365msec
WRITE: bw=235MiB/s (246MB/s), 235MiB/s-235MiB/s (246MB/s-246MB/s),
io=4096MiB (4295MB), run=17466-17466msec
WRITE: bw=235MiB/s (246MB/s), 235MiB/s-235MiB/s (246MB/s-246MB/s),
io=4096MiB (4295MB), run=17444-17444msec
WRITE: bw=241MiB/s (253MB/s), 241MiB/s-241MiB/s (253MB/s-253MB/s),
io=4096MiB (4295MB), run=17003-17003msec
WRITE: bw=236MiB/s (247MB/s), 236MiB/s-236MiB/s (247MB/s-247MB/s),
io=4096MiB (4295MB), run=17361-17361msec
WRITE: bw=244MiB/s (256MB/s), 244MiB/s-244MiB/s (256MB/s-256MB/s),
io=4096MiB (4295MB), run=16777-16777msec
--- Request timeouts with one timer per request (approach from v6 [1]) ---
Saw around ~232 MiB/s
WRITE: bw=230MiB/s (241MB/s), 230MiB/s-230MiB/s (241MB/s-241MB/s),
io=4096MiB (4295MB), run=17816-17816msec
WRITE: bw=233MiB/s (244MB/s), 233MiB/s-233MiB/s (244MB/s-244MB/s),
io=4096MiB (4295MB), run=17613-17613msec
WRITE: bw=231MiB/s (242MB/s), 231MiB/s-231MiB/s (242MB/s-242MB/s),
io=4096MiB (4295MB), run=17716-17716msec
WRITE: bw=231MiB/s (242MB/s), 231MiB/s-231MiB/s (242MB/s-242MB/s),
io=4096MiB (4295MB), run=17728-17728msec
WRITE: bw=233MiB/s (244MB/s), 233MiB/s-233MiB/s (244MB/s-244MB/s),
io=4096MiB (4295MB), run=17578-17578msec
WRITE: bw=232MiB/s (243MB/s), 232MiB/s-232MiB/s (243MB/s-243MB/s),
io=4096MiB (4295MB), run=17676-17676msec
WRITE: bw=231MiB/s (242MB/s), 231MiB/s-231MiB/s (242MB/s-242MB/s),
io=4096MiB (4295MB), run=17761-17761msec
WRITE: bw=234MiB/s (245MB/s), 234MiB/s-234MiB/s (245MB/s-245MB/s),
io=4096MiB (4295MB), run=17529-17529msec
WRITE: bw=230MiB/s (241MB/s), 230MiB/s-230MiB/s (241MB/s-241MB/s),
io=4096MiB (4295MB), run=17823-17823msec
WRITE: bw=235MiB/s (247MB/s), 235MiB/s-235MiB/s (247MB/s-247MB/s),
io=4096MiB (4295MB), run=17393-17393msec
Overall
- request timeouts with a periodic timer performs better than the
approach in v6 of attaching one timer to each request.
- I didn't see a significant difference in performance with enabling
timers when running non-passthrough fuse server, but did see about a
3% drop on passthrough servers
Thanks,
Joanne
[1] https://lore.kernel.org/linux-fsdevel/20240830162649.3849586-1-joannelkoong@gmail.com/
^ permalink raw reply [flat|nested] 9+ messages in thread