From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34A6CC76190 for ; Mon, 22 Jul 2019 15:13:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 13A4821842 for ; Mon, 22 Jul 2019 15:13:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728030AbfGVPNC (ORCPT ); Mon, 22 Jul 2019 11:13:02 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:49668 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727343AbfGVPNA (ORCPT ); Mon, 22 Jul 2019 11:13:00 -0400 Received: from callcc.thunk.org (guestnat-104-133-0-99.corp.google.com [104.133.0.99] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6MFCQsi029018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jul 2019 11:12:27 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 4D51E4202F5; Mon, 22 Jul 2019 11:12:26 -0400 (EDT) Date: Mon, 22 Jul 2019 11:12:26 -0400 From: "Theodore Y. Ts'o" To: Gao Xiang Cc: dsterba@suse.cz, Gao Xiang , Alexander Viro , Greg Kroah-Hartman , Andrew Morton , Stephen Rothwell , Linus Torvalds , linux-fsdevel@vger.kernel.org, devel@driverdev.osuosl.org, LKML , linux-erofs@lists.ozlabs.org, Chao Yu , Miao Xie , Li Guifu , Fang Wei Subject: Re: [PATCH v3 23/24] erofs: introduce cached decompression Message-ID: <20190722151226.GC5172@mit.edu> Mail-Followup-To: "Theodore Y. Ts'o" , Gao Xiang , dsterba@suse.cz, Gao Xiang , Alexander Viro , Greg Kroah-Hartman , Andrew Morton , Stephen Rothwell , Linus Torvalds , linux-fsdevel@vger.kernel.org, devel@driverdev.osuosl.org, LKML , linux-erofs@lists.ozlabs.org, Chao Yu , Miao Xie , Li Guifu , Fang Wei References: <20190722025043.166344-1-gaoxiang25@huawei.com> <20190722025043.166344-24-gaoxiang25@huawei.com> <20190722101818.GN20977@twin.jikos.cz> <41f1659a-0d16-4316-34fc-335b7d142d5c@aol.com> <20190722132513.GA5172@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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