On Fri, 22 Apr 2022 at 17:20, Bernd Schubert <bschubert@xxxxxxx> wrote: > > > > On 4/22/22 16:48, Miklos Szeredi wrote: > > On Fri, 22 Apr 2022 at 16:30, Dharmendra Hans <dharamhans87@xxxxxxxxx> wrote: > >> > >> On Thu, Apr 21, 2022 at 8:52 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > >>> > >>> On Fri, 8 Apr 2022 at 08:18, Dharmendra Singh <dharamhans87@xxxxxxxxx> wrote: > >>>> > > > > That's true, but I still worry... Does your workload include > > non-append extending writes? Seems to me making those run in parallel > > is asking for trouble. > > Our main use case is MPIIO for now and I don't think it first sets the > file size and would then write to these sparse files. Fixing all the > different MPI implementations including closed source stacks is probably > out of question. Okay. > Given that MPIIO also supports direct calls into its stack we also do > support that for some MPIs, but not all stacks. Direct calls bypassing > the vfs also haas it's own issues, including security. So it would be > really great if we could find a way to avoid the inode lock. > > Would you mind to share what you worry about in detail? I worry about breaking the assumption about i_size does not change if inode lock is held (exclusive of shared). Maybe that's not an issue, but we'd need to look very carefully. Thanks, Miklos
