From: Russ Fellows <russ.fellows@gmail.com>
To: miklos@szeredi.hu
Cc: fuse-devel@lists.linux.dev, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, amir73il@gmail.com,
Russ Fellows <rfellows@xlrait.dev>
Subject: [PATCH v2 0/2] fuse: fix passthrough parallel direct writes with a minimal series
Date: Tue, 16 Jun 2026 01:44:17 +0000 [thread overview]
Message-ID: <20260616014419.7913-1-russ.fellows@gmail.com> (raw)
In-Reply-To: <20260529031918.7361-1-russ.fellows@gmail.com>
From: Russ Fellows <rfellows@xlrait.dev>
This series contains the current minimal submit-ready fix for passthrough write
parallelism.
The first patch preserves FOPEN_PARALLEL_DIRECT_WRITES for passthrough opens.
Without that, fuse_file_io_open() strips the flag before passthrough writes see
it, so the kernel never reaches the shared-lock path.
The second patch keeps the lock decision local to passthrough.c and allows
shared inode locking only for safe direct overwrite writes. Append writes,
buffered writes, and writes that may extend EOF remain serialized.
This intentionally replaces the older broader patch direction. The current
minimal series does not export fuse_dio_lock()/fuse_dio_unlock() from file.c,
does not add declarations to fuse_i.h, and does not include the separate
iocachectr/fi->lock cleanup work.
Regarding fuse_passthrough_end_write() safety: the shared lock is only taken
for within-EOF direct overwrites, where i_size does not change. In that case
fuse_passthrough_end_write() -> fuse_write_update_attr() only updates mtime/
ctime, which is safe under a shared inode lock. Past-EOF writes still take
the exclusive lock, so i_size updates are always serialized correctly.
Validated on kernel 6.17.13-p4min with fio 4K random direct writes on a FUSE
passthrough mount backed by XFS on a RAM-backed null_blk device:
numjobs | FUSE IOPS
--------|----------
1 | 481,837
2 | 931,883
4 | 1,533,058
8 | 1,730,477
Raw XFS on the same device at numjobs=8: 1,693,406 IOPS.
Changes since v1:
- Removed use of fuse_dio_lock()/fuse_dio_unlock() from file.c; the lock
decision is now self-contained in passthrough.c using inode_lock_shared()
and inode_unlock_shared() directly.
- Added explicit IOCB_DIRECT check: parallel locking is only allowed for
direct I/O, preventing accidental shared locking on buffered writes.
- Added explicit IOCB_APPEND check: append writes always serialize.
- Added explicit past-EOF check: writes that extend i_size always serialize.
- Removed all symbol exports from file.c (fuse_dio_lock, fuse_dio_unlock).
- Removed all declarations added to fuse_i.h.
- Split into two patches: iomode.c flag preservation as a prerequisite
(patch 1) and passthrough.c locking logic as the main change (patch 2).
Russ Fellows (2):
fuse: preserve FOPEN_PARALLEL_DIRECT_WRITES for passthrough opens
fuse: allow parallel direct writes in passthrough write_iter
fs/fuse/iomode.c | 7 +++++--
fs/fuse/passthrough.c | 46 ++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 49 insertions(+), 4 deletions(-)
--
2.51.0
next prev parent reply other threads:[~2026-06-16 1:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 3:19 [PATCH 0/2] fuse: fix and optimize parallel writes on passthrough mounts Russ Fellows
2026-05-29 3:19 ` [PATCH 1/2] fuse: fix FOPEN_PARALLEL_DIRECT_WRITES being ignored for passthrough writes Russ Fellows
2026-06-01 18:52 ` Amir Goldstein
2026-06-01 19:25 ` Russ Fellows
2026-06-01 20:23 ` Amir Goldstein
2026-05-29 3:19 ` [PATCH 2/2] fuse: reduce fi->lock contention on parallel direct I/O Russ Fellows
2026-06-16 1:44 ` Russ Fellows [this message]
2026-06-16 1:44 ` [PATCH v2 1/2] fuse: preserve FOPEN_PARALLEL_DIRECT_WRITES for passthrough opens Russ Fellows
2026-06-16 11:06 ` Amir Goldstein
2026-06-16 1:44 ` [PATCH v2 2/2] fuse: allow parallel direct writes in passthrough write_iter Russ Fellows
2026-06-16 11:50 ` Amir Goldstein
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=20260616014419.7913-1-russ.fellows@gmail.com \
--to=russ.fellows@gmail.com \
--cc=amir73il@gmail.com \
--cc=fuse-devel@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=rfellows@xlrait.dev \
/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
all inboxes | Powered by JetHome®