Re: Possible deadlock in fuse write path (Was: Re: [PATCH 0/4] Some more lock_page work..)

[Miklos Szeredi <miklos@szeredi.hu>]

On Tue, Oct 20, 2020 at 10:42 PM Vivek Goyal <vgoyal@redhat.com> wrote:

> As you said, for the full page WRITE, we can probably mark it
> page uptodate write away and drop page lock (Keep reference and
> send WRITE request to fuse server). For the partial page write this will
> not work and there seem to be atleast two options.
>
> A. Either we read the page back from disk first and mark it uptodate.
>
> B. Or we keep track of such partial writes and block any further
>    reads/readpage/direct_IO on these pages till partial write is
>    complete. After that looks like page will be left notuptodate
>    in page cache and reader will read it from disk. We are doing
>    something similar for tracking writeback requests. It is much
>    more complicated though and we probably can design something
>    simpler for these writethrough/synchronous writes.
>
> I am assuming that A. will lead to performance penalty for short
> random writes.

C.  Keep partial tail page locked.  If write involves a partial and
head AND tail page, then read head page first.  I think that would be
a good compromise between performance and simplicity.

WDYT?

Thanks,
Miklos