On Thu, Jun 16, 2022 at 11:01:59AM +0200, Miklos Szeredi wrote: > 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. Ok. Agreed that non-extending parallel writes are safer option. Atleast for the case 1) above. For case 2) we can get multiple parallel extending writes with these patches if another client on another machine truncates file. So I don't have any objections to these patches. I just wanted to understand it better. Thanks Vivek
