Re: [PATCH 1/2] fuse: fix FOPEN_PARALLEL_DIRECT_WRITES being ignored for passthrough writes

[Amir Goldstein]

On Mon, Jun 1, 2026 at 9:25 PM Russ Fellows <russ.fellows@xxxxxxxxx> wrote:

> > On Jun 1, 2026, at 12:52 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> >
> > Removing stable list - this is definetly NOT a bug fix
> > Please CC fuse-devel@xxxxxxxxxxxxxxx for future fuse patches
> >
> >
> > Not a fix, because this was very intentional.
> > It is a new feature that you are proposing to support parallel
> > passthrough dio.
> >
> > Anyway, this patch has many problems
> >
> >>
> >
> > You can't just use fuse_dio_lock() like this
> > it plays nasty games with the iomode.
> > It does not even check for O_DIRECT mode, so this would do
> > parallel buffered write (at least until it meets the filesystem lock
> > but its not something we would want.
> > You should study this code better.
> >
> >>      ret = backing_file_write_iter(backing_file, iter, iocb, iocb->ki_flags,
> >>                                    &ctx);
> >
> > The problem is that while backing_file_write_iter() does not seem to
> > directly require an exclusive lock (apart from maybe file_remove_privs)
> > the fuse_passthrough_end_write() callback does I think rely on this
> > exclusive lock.
> >
> > So proving that this can work will require more research and more effort
> > and I am not really sure how that is going to work out.
> >
> > Thanks,
> > Amir.
>

No "top posting" in the mailing list please :)

>
> Amir,
>
> I appreciate your feedback.  I will review and revise my proposed changes.
>
> I will also remove the “fix” tag and mark this as an enhancement to FUSE parallel I/O.
>
> As an aside, I have tested the kernel changes quite a bit and have had no crashes or corruption,

I believe that but the corner cases of parallel dio with extending
writes are the
devil in the details and its unlikely that you covered those without
very deliberate testing
I am not saying there is a race but takes a lot of proof to remove a
lock and this
proof is on the one trying to remove it.

> and the write performance is 3x.

I believe that but can't just remove the lock and show the performance

>  But, I will use your input to focus these changes more appropriately and eliminate  their unintended consequences.
>

My instinct is that it might be easier to do this with PASSTHROUGH_INO [1]
where the attributes are always read from the backing inode, so less
races to worry about.

Good luck,
Amir.

[1] https://lore.kernel.org/fuse-devel/20260516004004.1455526-2-joannelkoong@xxxxxxxxx/