Re: [PATCH v4 1/1] Allow non-extending parallel direct writes on the same file.

[Miklos Szeredi]

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