[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5001fe8-217a-42bc-9257-45bef544762e@aol.com>
Date: Tue, 23 Jul 2019 00:27:16 +0800
From: Gao Xiang <hsiangkao@....com>
To: "Theodore Y. Ts'o" <tytso@....edu>
Cc: dsterba@...e.cz, Gao Xiang <gaoxiang25@...wei.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, devel@...verdev.osuosl.org,
LKML <linux-kernel@...r.kernel.org>,
linux-erofs@...ts.ozlabs.org, Chao Yu <yuchao0@...wei.com>,
Miao Xie <miaoxie@...wei.com>,
Li Guifu <bluce.liguifu@...wei.com>,
Fang Wei <fangwei1@...wei.com>
Subject: Re: [PATCH v3 23/24] erofs: introduce cached decompression
On 2019/7/22 ????11:12, Theodore Y. Ts'o wrote:
> On Mon, Jul 22, 2019 at 10:16:44PM +0800, Gao Xiang wrote:
>> OK, I will give a try. One point I think is how to deal with the case
>> if there is already cached information when remounting as well as you said.
>>
>> As the first step, maybe the mount option can be defined as
>> allowing/forbiding caching from now on, which can be refined later.
>
> Yes; possible solutions include ignoring the issue (assuming that
> cached data structures that "shouldn't" be in the cache given the new
> cache strategy will fall out of the cache over time), forcibly
> flushing the cache when the caching strategy has changed, and of
> course, forbidding caching strategy change at remount time.
Okay, thanks for your kindly suggestion :)
will do, hopefully resend this week (I agree less bugs with less
kernel configs.).
Thanks,
Gao Xiang
>
> Cheers,
>
> - Ted
>
Powered by blists - more mailing lists