Messages in this thread | | | From | Miklos Szeredi <> | Date | Thu, 16 Jun 2022 11:01:59 +0200 | Subject | Re: [PATCH v4 1/1] Allow non-extending parallel direct writes on the same file. |
| |
On Thu, 9 Jun 2022 at 15:53, Vivek Goyal <vgoyal@redhat.com> 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
| |