All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fengnan Chang <changfengnan@vivo.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2] fuse: use newer inode info when writeback cache is enabled
Date: Tue, 22 Jun 2021 20:25:11 +0800	[thread overview]
Message-ID: <3e740389-9734-a959-a88a-3b1d54b59e22@vivo.com> (raw)
In-Reply-To: <CAJfpegutK2HGYUtJOjvceULf2H=hoekNxUbcg=6Su6uteVmDLg@mail.gmail.com>

Unh, it seems i_writecount not work.
If we modify file through lowerfs, i_writecount won't change, but the 
size already changed.
For example:
echo "111" > /lowerfs/test
ls -l /upper/test
echo "2222" >> /lowerfs/test
ls -l /upper/test

So, can you describe your test enviroment? including kernel version and 
fsx parameters, I will check it.

Thanks.

On 2021/6/22 15:59, Miklos Szeredi wrote:
> On Sat, 30 Jan 2021 at 09:50, Fengnan Chang <changfengnan@vivo.com> wrote:
>>
>> When writeback cache is enabled, the inode information in cached is
>> considered new by default, and the inode information of lowerfs is
>> stale.
>> When a lower fs is mount in a different directory through different
>> connection, for example PATHA and PATHB, since writeback cache is
>> enabled by default, when the file is modified through PATHA, viewing the
>> same file from the PATHB, PATHB will think that cached inode is newer
>> than lowerfs, resulting in file size and time from under PATHA and PATHB
>> is inconsistent.
>> Add a judgment condition to check whether to use the info in the cache
>> according to mtime.
> 
> This seems to break the fsx-linux stress test.
> 
> I suspect a better direction would be looking at whether the inode has
> any files open for write (i_writecount > 0)...
> 
> Thanks,
> Miklos
> 

  reply	other threads:[~2021-06-22 12:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-30  8:50 [PATCH v2] fuse: use newer inode info when writeback cache is enabled Fengnan Chang
2021-05-07 10:04 ` Fengnan Chang
2021-06-22  7:59 ` Miklos Szeredi
2021-06-22 12:25   ` Fengnan Chang [this message]
2021-06-22 15:19     ` Miklos Szeredi
2021-06-24  7:42       ` Fengnan Chang
2021-06-25  3:42         ` Fengnan Chang
2021-08-06 12:20         ` Miklos Szeredi
2021-08-10  1:41           ` Fengnan Chang
2021-08-16  2:48             ` Peng Tao
2021-05-07 10:09 changfengnan
2021-05-11 11:21 ` 答复: " changfengnan
2021-05-12 12:33   ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3e740389-9734-a959-a88a-3b1d54b59e22@vivo.com \
    --to=changfengnan@vivo.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.