On Thu, 9 Jun 2022 at 15:53, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > Right. If user space is relying on kernel lock for thread synchronization, > it can not enable parallel writes. > > But if it is not relying on this, it should be able to enable parallel > writes. Just keep in mind that ->i_size check is not sufficient to > guarantee that you will not get "two extnding parallel writes". If > another client on a different machine truncated the file, it is > possible this client has old cached ->i_size and it will can > get multiple file extending parallel writes. There are two cases: 1. the filesystem can be changed only through a single fuse instance 2. the filesystem can be changed externally. In case 1 the fuse client must ensure that data is updated consistently (as defined by e.g. POSIX). This is what I'm mostly worried about. Case 2 is much more difficult in the general case, and network filesystems often have a relaxed consistency model. > So if fuse daemon enables parallel extending writes, it should be > prepared to deal with multiple extending parallel writes. > > And if this is correct assumption, I am wondering why to even try > to do ->i_size check and try to avoid parallel extending writes > in fuse kernel. May be there is something I am not aware of. And > that's why I am just raising questions. We can probably do that, but it needs careful review of where i_size is changed and where i_size is used so we can never get into an inconsistent state. Thanks, Miklos
