On 4/13/23 09:40, Miklos Szeredi wrote: > On Wed, 12 Apr 2023 at 15:42, Bernd Schubert <bschubert@xxxxxxx> wrote: >> >> Miklos, Jens, >> >> could we please also set this flag for fuse? >> >> >> Thanks, >> Bernd >> >> >> fuse: Set FMODE_DIO_PARALLEL_WRITE flag >> >> From: Bernd Schubert <bschubert@xxxxxxx> >> >> Fuse can also do parallel DIO writes, if userspace has enabled it. >> >> Signed-off-by: Bernd Schubert <bschubert@xxxxxxx> >> --- >> fs/fuse/file.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/fs/fuse/file.c b/fs/fuse/file.c >> index 875314ee6f59..46e7f1196fd1 100644 >> --- a/fs/fuse/file.c >> +++ b/fs/fuse/file.c >> @@ -215,6 +215,9 @@ void fuse_finish_open(struct inode *inode, struct file *file) >> } >> if ((file->f_mode & FMODE_WRITE) && fc->writeback_cache) >> fuse_link_write_file(file); >> + >> + if (ff->open_flags & FOPEN_PARALLEL_DIRECT_WRITES) >> + file->f_mode |= FMODE_DIO_PARALLEL_WRITE; > > fuse_direct_write_iter(): > > bool exclusive_lock = > !(ff->open_flags & FOPEN_PARALLEL_DIRECT_WRITES) || > iocb->ki_flags & IOCB_APPEND || > fuse_direct_write_extending_i_size(iocb, from); > > If the write is size extending, then it will take the lock exclusive. > OTOH, I guess that it would be unusual for lots of size extending > writes to be done in parallel. > > What would be the effect of giving the FMODE_DIO_PARALLEL_WRITE hint > and then still serializing the writes? It used here https://lore.kernel.org/io-uring/20230403-wound-roundworm-c1660e059b8c@brauner/T/#m5f86985d6c67dd1d01a977475dab542c338372dd fuse_finish_open has its own lock, so letting uring handle requests in parallel should not hurt? Is this going like application -> uring does parallel requests -> fuse.ko -> fuse-deamon So when fuse-deamon signals that it can handle parallel DIO, it is just fuse.ko that might need its own lock to extend the file? Thanks, Bernd
