| Message ID | 20190711145755.33908-1-gaoxiang25@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | erofs: promote erofs from staging | expand |
On Thu 2019-07-11 22:57:31, Gao Xiang wrote: > Changelog from v1: > o resend the whole filesystem into a patchset suggested by Greg; > o code is more cleaner, especially for decompression frontend. > > --8<---------- > > Hi, > > 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). Ok, maybe it is ready to be moved to kernel proper, but as git can do moves, would it be better to do it as one commit? Separate patches are still better for review, I guess. Pavel
Hi Pavel, On 2019/7/14 18:49, Pavel Machek Wrote: > On Thu 2019-07-11 22:57:31, Gao Xiang wrote: >> Changelog from v1: >> o resend the whole filesystem into a patchset suggested by Greg; >> o code is more cleaner, especially for decompression frontend. >> >> --8<---------- >> >> Hi, >> >> 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). > > Ok, maybe it is ready to be moved to kernel proper, but as git can > do moves, would it be better to do it as one commit? > > Separate patches are still better for review, I guess. Thanks for you reply. Either form is OK for me... The first step could be that I hope someone could kindly take some time to look into these patches... :) The patch v2 is slightly different for the current code in the staging tree since I did some code cleanup these days (mainly renaming / moving, including rename unzip_vle.{c,h} to zdata.{c,h} and some confusing structure names and clean up internal.h...). No functional chance and I can submit cleanup patches to staging as well if doing moves by git... Thanks, Gao Xiang > Pavel >
Hi! > >> Changelog from v1: > >> o resend the whole filesystem into a patchset suggested by Greg; > >> o code is more cleaner, especially for decompression frontend. > >> > >> --8<---------- > >> > >> Hi, > >> > >> 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). > > > > Ok, maybe it is ready to be moved to kernel proper, but as git can > > do moves, would it be better to do it as one commit? > > > > Separate patches are still better for review, I guess. > > Thanks for you reply. Either form is OK for me... The first step could > be that I hope someone could kindly take some time to look into these > patches... :) > > The patch v2 is slightly different for the current code in the staging > tree since I did some code cleanup these days (mainly renaming / moving, > including rename unzip_vle.{c,h} to zdata.{c,h} and some confusing > structure names and clean up internal.h...). No functional chance and I > can submit cleanup patches to staging as well if doing moves by git... I believe you should get those committed to staging/, yes. Then you ask Al Viro to do pull the git move, I guess, and you follow his instructions at that point... FILESYSTEMS (VFS and infrastructure) M: Alexander Viro <viro@zeniv.linux.org.uk> L: linux-fsdevel@vger.kernel.org Best regards, Pavel
On 2019/7/15 15:56, Pavel Machek wrote: > Hi! > >>>> Changelog from v1: >>>> o resend the whole filesystem into a patchset suggested by Greg; >>>> o code is more cleaner, especially for decompression frontend. >>>> >>>> --8<---------- >>>> >>>> Hi, >>>> >>>> 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). >>> >>> Ok, maybe it is ready to be moved to kernel proper, but as git can >>> do moves, would it be better to do it as one commit? >>> >>> Separate patches are still better for review, I guess. >> >> Thanks for you reply. Either form is OK for me... The first step could >> be that I hope someone could kindly take some time to look into these >> patches... :) >> >> The patch v2 is slightly different for the current code in the staging >> tree since I did some code cleanup these days (mainly renaming / moving, >> including rename unzip_vle.{c,h} to zdata.{c,h} and some confusing >> structure names and clean up internal.h...). No functional chance and I >> can submit cleanup patches to staging as well if doing moves by git... > > I believe you should get those committed to staging/, yes. Then you > ask Al Viro to do pull the git move, I guess, and you follow his > instructions at that point... > > FILESYSTEMS (VFS and infrastructure) > M: Alexander Viro <viro@zeniv.linux.org.uk> > L: linux-fsdevel@vger.kernel.org OK, I will send the incremental patches as well later if the above approach can be done in practice... Actually I'd like to get fs people Acked-by about EROFS stuffes, e.g. Al, Ted, etc... Hello? It seems rare filesystems upstreamed these years, but I think EROFS is more useful after moving out of staging. If some people really care about compression ratio, I can add multi-block fixed-output compression support later (Not very hard, it's already on my TODO list), although my current company HUAWEI doesn't have any interest in that way in the near future... In the long term, I'd like to spend my personal free time to decouple code like fscrypt and introduce fscompr for other generic fs to compress unmodified files as well then... That is another stuff. Anyway, EROFS is one of optimal read-only performance solutions for consumer electronics compared with others (Note that block storage has been improved a lot in the past decade...) Thank you very much, Gao Xiang > > Best regards, > Pavel >
Changelog from v1: o resend the whole filesystem into a patchset suggested by Greg; o code is more cleaner, especially for decompression frontend. --8<---------- Hi, 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. Thank you very much, Gao Xiang [1] http://web.archive.org/web/20190627021241/https://consumer.huawei.com/en/emui/ [2] https://lore.kernel.org/lkml/20190624072258.28362-1-hsiangkao@aol.com/ Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Chao Yu <yuchao0@huawei.com> Cc: Miao Xie <miaoxie@huawei.com> Cc: Li Guifu <bluce.liguifu@huawei.com> Cc: Fang Wei <fangwei1@huawei.com> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com> Gao Xiang (24): erofs: add on-disk layout erofs: add erofs in-memory stuffs erofs: add super block operations erofs: add raw address_space operations erofs: add inode operations erofs: support special inode erofs: add directory operations erofs: add namei functions erofs: support tracepoint erofs: update Kconfig and Makefile erofs: introduce xattr & posixacl support erofs: introduce tagged pointer erofs: add compression indexes support erofs: introduce superblock registration erofs: introduce erofs shrinker erofs: introduce workstation for decompression erofs: introduce per-CPU buffers implementation erofs: introduce pagevec for decompression subsystem erofs: add erofs_allocpage() erofs: introduce generic decompression backend erofs: introduce LZ4 decompression inplace erofs: introduce the decompression frontend erofs: introduce cached decompression erofs: add document Documentation/filesystems/erofs.txt | 211 ++++ fs/Kconfig | 1 + fs/Makefile | 1 + fs/erofs/Kconfig | 154 +++ fs/erofs/Makefile | 11 + fs/erofs/compress.h | 89 ++ fs/erofs/data.c | 390 ++++++++ fs/erofs/decompressor.c | 329 ++++++ fs/erofs/dir.c | 147 +++ fs/erofs/erofs_fs.h | 317 ++++++ fs/erofs/inode.c | 326 ++++++ fs/erofs/internal.h | 566 +++++++++++ fs/erofs/namei.c | 250 +++++ fs/erofs/super.c | 616 ++++++++++++ fs/erofs/tagptr.h | 110 ++ fs/erofs/utils.c | 416 ++++++++ fs/erofs/xattr.c | 700 +++++++++++++ fs/erofs/xattr.h | 93 ++ fs/erofs/zdata.c | 1439 +++++++++++++++++++++++++++ fs/erofs/zdata.h | 201 ++++ fs/erofs/zmap.c | 462 +++++++++ fs/erofs/zpvec.h | 159 +++ include/trace/events/erofs.h | 256 +++++ 23 files changed, 7244 insertions(+) create mode 100644 Documentation/filesystems/erofs.txt create mode 100644 fs/erofs/Kconfig create mode 100644 fs/erofs/Makefile create mode 100644 fs/erofs/compress.h create mode 100644 fs/erofs/data.c create mode 100644 fs/erofs/decompressor.c create mode 100644 fs/erofs/dir.c create mode 100644 fs/erofs/erofs_fs.h create mode 100644 fs/erofs/inode.c create mode 100644 fs/erofs/internal.h create mode 100644 fs/erofs/namei.c create mode 100644 fs/erofs/super.c create mode 100644 fs/erofs/tagptr.h create mode 100644 fs/erofs/utils.c create mode 100644 fs/erofs/xattr.c create mode 100644 fs/erofs/xattr.h create mode 100644 fs/erofs/zdata.c create mode 100644 fs/erofs/zdata.h create mode 100644 fs/erofs/zmap.c create mode 100644 fs/erofs/zpvec.h create mode 100644 include/trace/events/erofs.h