[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190722151226.GC5172@mit.edu>
Date: Mon, 22 Jul 2019 11:12:26 -0400
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Gao Xiang <hsiangkao@....com>
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 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.
Cheers,
- Ted
Powered by blists - more mailing lists