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.3 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,USER_AGENT_SANE_1 autolearn=unavailable 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 B98C1C433FF for ; Thu, 15 Aug 2019 09:06:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 90F36218AD for ; Thu, 15 Aug 2019 09:06:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565859970; bh=Mc3YrEyyDx8AvnWtpvQCsXoWv0AaiAhsDt9By4lPmxc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=PcmhL0WzyqqHrEe6oSCk2hcn3qbDYcmgSDgFnGFZ3RcQr9cdLJtu0xc2hpHcPh0u2 DMaOHny6snhE4sE4s2jsRvxOPJJ20poxQwFpnw9lZ9tOMAlsoSECzX0TuehrHKTUUP xDo1pNnGIIyjUC0RMRo1sqkI+MgTfA7TYM5iAuHM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730749AbfHOJGG (ORCPT ); Thu, 15 Aug 2019 05:06:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:52584 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730212AbfHOJGG (ORCPT ); Thu, 15 Aug 2019 05:06:06 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 CEF3A218A6; Thu, 15 Aug 2019 09:06:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565859965; bh=Mc3YrEyyDx8AvnWtpvQCsXoWv0AaiAhsDt9By4lPmxc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=K3L5k2vJ2kFpsG2wfCLVkOngcZzZqI9yll1frug6xM0uM7bdwF/+iA26VOaSAndDN v6ed2vDKBv2obKuG2LL7maD7MOtU/i9uIyZSa3nZVUd+iYA5s3wlBu9pi47qQOVRbO /OliDX5MrGyc2/QiINacfpFQxVdBu/vbpytThbqc= Date: Thu, 15 Aug 2019 11:06:03 +0200 From: Greg Kroah-Hartman To: Gao Xiang Cc: linux-fsdevel@vger.kernel.org, devel@driverdev.osuosl.org, Alexander Viro , Stephen Rothwell , linux-erofs@lists.ozlabs.org, Chao Yu , Theodore Ts'o , "Darrick J . Wong" , Pavel Machek , Jan Kara , Amir Goldstein , Dave Chinner , LKML , Li Guifu , David Sterba , Christoph Hellwig , Richard Weinberger , Miao Xie , Fang Wei , Jaegeuk Kim , Andrew Morton , Linus Torvalds Subject: Re: [PATCH v8 00/24] erofs: promote erofs from staging v8 Message-ID: <20190815090603.GD4938@kroah.com> References: <20190815044155.88483-1-gaoxiang25@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190815044155.88483-1-gaoxiang25@huawei.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Aug 15, 2019 at 12:41:31PM +0800, Gao Xiang wrote: > [I strip the previous cover letter, the old one can be found in v6: > https://lore.kernel.org/r/20190802125347.166018-1-gaoxiang25@huawei.com/] > > We'd like to submit a formal moving patch applied to staging tree > for 5.4, before that we'd like to hear if there are some ACKs, > suggestions or NAKs, objections of EROFS. Therefore, we can improve > it in this round or rethink about the whole thing. > > As related materials mentioned [1] [2], the goal of EROFS is to > save extra storage space with guaranteed end-to-end performance > for read-only files, which has better performance over exist Linux > compression filesystems based on fixed-sized output compression > and inplace decompression. It even has better performance in > a large compression ratio range compared with generic uncompressed > filesystems with proper CPU-storage combinations. And we think this > direction is correct and a dedicated kernel team is continuously / > actively working on improving it, enough testers and beta / end > users using it. > > EROFS has been applied to almost all in-service HUAWEI smartphones > (Yes, the number is still increasing by time) and it seems like > a success. It can be used in more wider scenarios. We think it's > useful for Linux / Android OS community and it's the time moving > out of staging. > > In order to get started, latest stable mkfs.erofs is available at > > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git -b dev > > with README in the repository. > > We are still tuning sequential read performance for ultra-fast > speed NVME SSDs like Samsung 970PRO, but at least now you can > try on your PC with some data with proper compression ratio, > the latest Linux kernel, USB stick for convenience sake and > a not very old-fashioned CPU. There are also benchmarks available > in the above materials mentioned. > > EROFS is a self-contained filesystem driver. Although there are > still some TODOs to be more generic, we will actively keep on > developping / tuning EROFS with the evolution of Linux kernel > as the other in-kernel filesystems. > > As I mentioned before in LSF/MM 2019, in the future, we'd like > to generalize the decompression engine into a library for other > fses to use after the whole system is mature like fscrypt. > However, such metadata should be designed respectively for > each fs, and synchronous metadata read cost will be larger > than EROFS because of those ondisk limitation. Therefore EROFS > is still a better choice for read-only scenarios. > > EROFS is now ready for reviewing and moving, and the code is > already cleaned up as shiny floors... Please kindly take some > precious time, share your comments about EROFS and let us know > your opinion about this. It's really important for us since > generally speaking, we like to use Linux _in-tree_ stuffs rather > than lack of supported out-of-tree / orphan stuffs as well. I know everyone is busy, but given the length this has been in staging, and the constant good progress toward cleaning it all up that has been happening, I want to get this moved out of staging soon. So, unless there are any objections, I'll take this patchset in a week into my staging tree to move the filesystem into the "real" part of the kernel. thanks, greg k-h