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=-7.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 D59E5C0651F for ; Thu, 4 Jul 2019 13:50:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A7D98218AD for ; Thu, 4 Jul 2019 13:50:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562248209; bh=4PW5nvqwyM7OR+LkvB9HftlbPSqldTl/coy/yvrWKxU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=MZBp4ymUUY/WNpaHTW0mMpmmgHEycIQM+z7LfywBlaAEdrheX2bCAJBd2kDp6urtt p/X1FBI1qCSuCe7/2aIcHlQUbx491ygmWmXq93gKJOMNc+Rg1c60Zr+02AtvpE0wNT H1XPwjpirjpGaqqDXFQANSgC47SXE/KUgbNAQoRM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727312AbfGDNuI (ORCPT ); Thu, 4 Jul 2019 09:50:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:57946 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727026AbfGDNuI (ORCPT ); Thu, 4 Jul 2019 09:50:08 -0400 Received: from localhost (unknown [89.205.128.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3B59A2189E; Thu, 4 Jul 2019 13:50:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562248207; bh=4PW5nvqwyM7OR+LkvB9HftlbPSqldTl/coy/yvrWKxU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ucoXT08wHmr8LEIrhMwCPFo2B2CESRhk4c1QaPyOMSVIVfwKpp2wK4u2CWjB9E6jK IjY5K1wr3jyZvhQWV6j0EzxOjN4gNXVcLQJ7RE6r7BOeVog2NHJ8erjRCxGhtuB9AY W0BjsmE4xg0UCS9jTo+EmWl7a90CBqzFPDPzQlwM= Date: Thu, 4 Jul 2019 15:50:02 +0200 From: Greg Kroah-Hartman To: Gao Xiang Cc: Alexander Viro , Andrew Morton , Theodore Ts'o , Linus Torvalds , devel@driverdev.osuosl.org, Miao Xie , Chao Yu , LKML , Li Guifu , Fang Wei , linux-fsdevel@vger.kernel.org, linux-erofs@lists.ozlabs.org Subject: Re: [PATCH] erofs: promote erofs from staging Message-ID: <20190704135002.GB13609@kroah.com> References: <20190704133413.43012-1-gaoxiang25@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190704133413.43012-1-gaoxiang25@huawei.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 04, 2019 at 09:34:13PM +0800, Gao Xiang wrote: > EROFS file system has been in Linux-staging for about a year. > It has been proved to be stable enough to move out of staging > by 10+ millions of HUAWEI Android mobile phones on the market > from EMUI 9.0.1, and it was promoted as one of the key features > of EMUI 9.1 [1], including P30(pro). > > EROFS is a read-only file system designed to save extra storage > space with guaranteed end-to-end performance by applying > fixed-size output compression, inplace I/O and decompression > inplace technologies [2] to Linux filesystem. > > In our observation, EROFS is one of the fastest Linux compression > filesystem using buffered I/O in the world. It will support > direct I/O in the future if needed. EROFS even has better read > performance in a large CR range compared with generic uncompressed > file systems with proper CPU-storage combination, which is > a reason why erofs can be landed to speed up mobile phone > performance, and which can be probably used for other use cases > such as LiveCD and Docker image as well. > > Currently erofs supports 4k LZ4 fixed-size output compression > since LZ4 is the fastest widely-used decompression solution in > the world and 4k leads to unnoticable read amplification for > the worst case. More compression algorithms and cluster sizes > could be added later, which depends on the real requirement. > > More informations about erofs itself are available at: > Documentation/filesystems/erofs.txt > https://kccncosschn19eng.sched.com/event/Nru2/erofs-an-introduction-and-our-smartphone-practice-xiang-gao-huawei > > erofs-utils (mainly mkfs.erofs now) is available at > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git > > Preliminary iomap support has been pending in erofs mailing > list by Chao Yu. The key issue is that current iomap doesn't > support tail-end packing inline data yet, it should be > resolved later. > > Thanks to many contributors in the last year, the code is more > clean and improved. We hope erofs can be used in wider use cases > so let's promote erofs out of staging and enhance it more actively. > > Share comments about erofs! We think erofs is useful to > community as a part of Linux upstream :) I don't know if this format is easy for the linux-fsdevel people to review, it forces them to look at the in-kernel code, which makes it hard to quote. Perhaps just make a patch that adds the filesystem to the tree and after it makes it through review, I can delete the staging version? We've been doing that for wifi drivers that move out of staging as it seems to be a bit easier. thanks, greg k-h