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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 C4AFAC3A59E for ; Mon, 2 Sep 2019 15:51:39 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A4D8E21744 for ; Mon, 2 Sep 2019 15:51:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A4D8E21744 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 77CEE21546; Mon, 2 Sep 2019 15:51:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A3hu42ile3B; Mon, 2 Sep 2019 15:51:36 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by silver.osuosl.org (Postfix) with ESMTP id 9C1FA2154A; Mon, 2 Sep 2019 15:51:36 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id 897C51BF32D for ; Mon, 2 Sep 2019 15:51:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 85177864D8 for ; Mon, 2 Sep 2019 15:51:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozHDC8X8c7qj for ; Mon, 2 Sep 2019 15:51:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from huawei.com (szxga02-in.huawei.com [45.249.212.188]) by whitealder.osuosl.org (Postfix) with ESMTPS id 4DB6C864D2 for ; Mon, 2 Sep 2019 15:51:33 +0000 (UTC) Received: from DGGEMM404-HUB.china.huawei.com (unknown [172.30.72.56]) by Forcepoint Email with ESMTP id D87F48830A7DEFEEDC58; Mon, 2 Sep 2019 23:51:29 +0800 (CST) Received: from dggeme762-chm.china.huawei.com (10.3.19.108) by DGGEMM404-HUB.china.huawei.com (10.3.20.212) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 2 Sep 2019 23:51:29 +0800 Received: from architecture4 (10.140.130.215) by dggeme762-chm.china.huawei.com (10.3.19.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 2 Sep 2019 23:51:29 +0800 Date: Mon, 2 Sep 2019 23:50:38 +0800 From: Gao Xiang To: Christoph Hellwig Subject: Re: [PATCH 00/21] erofs: patchset addressing Christoph's comments Message-ID: <20190902155037.GD179615@architecture4> References: <20190802125347.166018-1-gaoxiang25@huawei.com> <20190901055130.30572-1-hsiangkao@aol.com> <20190902124645.GA8369@infradead.org> <20190902142452.GE2664@architecture4> <20190902152323.GB14009@infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190902152323.GB14009@infradead.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [10.140.130.215] X-ClientProxiedBy: dggeme710-chm.china.huawei.com (10.1.199.106) To dggeme762-chm.china.huawei.com (10.3.19.108) X-CFilter-Loop: Reflected X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, Chao Yu , Greg Kroah-Hartman , linux-fsdevel@vger.kernel.org, linux-erofs@lists.ozlabs.org, Chao Yu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" Hi Christoph, On Mon, Sep 02, 2019 at 08:23:23AM -0700, Christoph Hellwig wrote: > On Mon, Sep 02, 2019 at 10:24:52PM +0800, Gao Xiang wrote: > > > code quality stuff. We're not addressing the issues with large amounts > > > of functionality duplicating VFS helpers. > > > > You means killing erofs_get_meta_page or avoid erofs_read_raw_page? > > > > - For killing erofs_get_meta_page, here is the current erofs_get_meta_page: > > > I think it is simple enough. read_cache_page need write a similar > > filler, or read_cache_page_gfp will call .readpage, and then > > introduce buffer_heads, that is what I'd like to avoid now (no need these > > bd_inode buffer_heads in memory...) > > If using read_cache_page_gfp and ->readpage works, please do. The > fact that the block device inode uses buffer heads is an implementation > detail that might not last very long and should be invisible to you. > It also means you can get rid of a lot of code that you don't have > to maintain and others don't have to update for global API changes. I care about those useless buffer_heads in memory for our products... Since we are nobh filesystem (a little request, could I use it after buffer_heads are fully avoided, I have no idea why I need those buffer_heads in memory.... But I think bd_inode is good for caching metadata...) > > > - For erofs_read_raw_page, it can be avoided after iomap tail-end packing > > feature is done... If we remove it now, it will make EROFS broken. > > It is no urgent and Chao will focus on iomap tail-end packing feature. > > Ok. I wish we would have just sorted this out beforehand, which we > could have trivially done without all that staging mess. Firstly, I'd like to introduce EROFS as a self-contained filesystem to introduce new fixed-sized output compression to upstream and promote it... And then we can do many improvements for EROFS in parallel... (if we introduce EROFS and touch many core modules like iomap, mm readahead code or modify LZ4 code at once... It could be more careful... Let's improve it step-by-step... We are a dedicated team if the Linux community needs us, we will still here... It will be actively maintained.) Thanks, Gao Xiang _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel