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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 20, 2020 at 10:42 PM Vivek Goyal <vgoyal@xxxxxxxxxx> 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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux