From: Gao Xiang <gaoxiang25@huawei.com> To: Christian Kujau <lists@nerdbynature.de> Cc: <linux-kernel@vger.kernel.org>, <linux-erofs@lists.ozlabs.org> Subject: Re: [PATCH 00/25] staging: erofs: introduce erofs file system Date: Fri, 27 Jul 2018 09:39:54 +0800 [thread overview] Message-ID: <bcb9e620-f73b-4dbc-630b-af925c3d8ebd@huawei.com> (raw) In-Reply-To: <alpine.DEB.2.21.999.1807261707460.11672@trent.utfs.org> Hi Christian, On 2018/7/27 8:25, Christian Kujau wrote: > On Thu, 26 Jul 2018, Gao Xiang wrote: >> EROFS file system is a read-only file system with compression >> support designed for certain devices (especially embeded >> devices) with very limited physical memory and lots of memory > Out of curiousity, and as Richard already asked[0] - what about existing > file system, why can't they be used or extended instead of introducing yet > another file system into the kernel? JFFS2? UBIFS? CramFs? SquashFS? > ROMFS? F2FS? YAFFS? > > Christian. > Every file system has its typical usage case. I don't think there exists a silver bullet solving all usage cases optimally. JFFS2, YAFFS and UBIFS are designed for raw flash, we use UFS or eMMC solution rather than raw nand flash. Cramfs and ROMFS are too simple for us, and it is actually useless because no similar & duplicate code with EROFS. We can save about 200MB+ metadata space than EXT4 by just using EROFS _without_ compression support in our products, which could be more compared with F2FS(F2FS has more useless metadata for read-only use such as SIT, and SSA). Since we are a read-only file system, we could use aggressive inline(compact) and data deduplication approach. It is not a small number storage space because we leave some compression ratio for better performance in low memory scenario. and I don't think SquashFS is optimal for us, 1) it doesn't have the inline consideration by design (inline could save storage space also reduce extra data IOs), 2) it is designed for saving more storage space rather than keeping high performance for limited physical memory scenario; 3) it has many compatible code for its historial design, actually its on-disk layout design is hard to be extended considering its historial images 4) It is not designed for VLE, we need to rewrite more than half of its current code 5) EROFS has no similar code with the current SquashFS. In the end, I don't think F2FS could be an expansion of NILFS2, BTRFS is an b-tree expansion of some read-write file system. You could call EROFS as ROMFS2 or Squashfs+ but EROFS is a completely different solution. We need to evaluate the optimal file system for each specific usage case (actually we think erofs almost reaches our requirements for our Android products rather than SquashFS) and KISS for each solution. Thanks for your reply :) Thanks, Gao Xiang > [0] https://marc.info/?l=linux-kernel&m=152783930418348&w=2
WARNING: multiple messages have this Message-ID (diff)
From: gaoxiang25@huawei.com (Gao Xiang) Subject: [PATCH 00/25] staging: erofs: introduce erofs file system Date: Fri, 27 Jul 2018 09:39:54 +0800 [thread overview] Message-ID: <bcb9e620-f73b-4dbc-630b-af925c3d8ebd@huawei.com> (raw) In-Reply-To: <alpine.DEB.2.21.999.1807261707460.11672@trent.utfs.org> Hi Christian, On 2018/7/27 8:25, Christian Kujau wrote: > On Thu, 26 Jul 2018, Gao Xiang wrote: >> EROFS file system is a read-only file system with compression >> support designed for certain devices (especially embeded >> devices) with very limited physical memory and lots of memory > Out of curiousity, and as Richard already asked[0] - what about existing > file system, why can't they be used or extended instead of introducing yet > another file system into the kernel? JFFS2? UBIFS? CramFs? SquashFS? > ROMFS? F2FS? YAFFS? > > Christian. > Every file system has its typical usage case. I don't think there exists a silver bullet solving all usage cases optimally. JFFS2, YAFFS and UBIFS are designed for raw flash, we use UFS or eMMC solution rather than raw nand flash. Cramfs and ROMFS are too simple for us, and it is actually useless because no similar & duplicate code with EROFS. We can save about 200MB+ metadata space than EXT4 by just using EROFS _without_ compression support in our products, which could be more compared with F2FS(F2FS has more useless metadata for read-only use such as SIT, and SSA). Since we are a read-only file system, we could use aggressive inline(compact) and data deduplication approach. It is not a small number storage space because we leave some compression ratio for better performance in low memory scenario. and I don't think SquashFS is optimal for us, 1) it doesn't have the inline consideration by design (inline could save storage space also reduce extra data IOs), 2) it is designed for saving more storage space rather than keeping high performance for limited physical memory scenario; 3) it has many compatible code for its historial design, actually its on-disk layout design is hard to be extended considering its historial images 4) It is not designed for VLE, we need to rewrite more than half of its current code 5) EROFS has no similar code with the current SquashFS. In the end, I don't think F2FS could be an expansion of NILFS2, BTRFS is an b-tree expansion of some read-write file system. You could call EROFS as ROMFS2 or Squashfs+ but EROFS is a completely different solution. We need to evaluate the optimal file system for each specific usage case (actually we think erofs almost reaches our requirements for our Android products rather than SquashFS) and KISS for each solution. Thanks for your reply :) Thanks, Gao Xiang > [0] https://marc.info/?l=linux-kernel&m=152783930418348&w=2
next prev parent reply other threads:[~2018-07-27 1:40 UTC|newest] Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-31 11:06 [NOMERGE] [RFC PATCH 00/12] erofs: introduce erofs file system Gao Xiang 2018-06-01 7:48 ` Richard Weinberger 2018-06-01 9:11 ` Gao Xiang 2018-06-01 9:28 ` Richard Weinberger 2018-06-01 11:16 ` Gao Xiang 2018-06-07 10:26 ` Pavel Machek 2018-07-27 0:55 ` Joey Pabalinas 2018-07-27 0:57 ` Joey Pabalinas 2018-07-26 12:21 ` [PATCH 00/25] staging: " Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 01/25] staging: erofs: add on-disk layout Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 02/25] staging: erofs: add erofs in-memory stuffs Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 03/25] staging: erofs: add super block operations Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 04/25] staging: erofs: add raw address_space operations Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 05/25] staging: erofs: add inode operations Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 06/25] staging: erofs: add directory operations Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 07/25] staging: erofs: add namei functions Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 08/25] staging: erofs: update Kconfig and Makefile Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 09/25] staging: erofs: introduce xattr & acl support Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 10/25] staging: erofs: support special inode Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 11/25] staging: erofs: introduce error injection infrastructure Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 12/25] staging: erofs: support tracepoint Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 13/25] staging: erofs: <linux/tagptr.h>: introduce tagged pointer Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 14/25] staging: erofs: introduce pagevec for unzip subsystem Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 15/25] staging: erofs: add erofs_map_blocks_iter Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:21 ` [PATCH 16/25] staging: erofs: add erofs_allocpage Gao Xiang 2018-07-26 12:21 ` Gao Xiang 2018-07-26 12:22 ` [PATCH 17/25] staging: erofs: globalize prepare_bio and __submit_bio Gao Xiang 2018-07-26 12:22 ` Gao Xiang 2018-07-26 12:22 ` [PATCH 18/25] staging: erofs: introduce a customized LZ4 decompression Gao Xiang 2018-07-26 12:22 ` Gao Xiang 2018-07-26 12:22 ` [PATCH 19/25] staging: erofs: add a generic z_erofs VLE decompressor Gao Xiang 2018-07-26 12:22 ` Gao Xiang 2018-07-26 12:22 ` [PATCH 20/25] staging: erofs: introduce superblock registration Gao Xiang 2018-07-26 12:22 ` Gao Xiang 2018-07-26 12:22 ` [PATCH 21/25] staging: erofs: introduce erofs shrinker Gao Xiang 2018-07-26 12:22 ` Gao Xiang 2018-07-26 12:22 ` [PATCH 22/25] staging: erofs: introduce workstation for decompression Gao Xiang 2018-07-26 12:22 ` Gao Xiang 2018-07-26 12:22 ` [PATCH 23/25] staging: erofs: introduce VLE decompression support Gao Xiang 2018-07-26 12:22 ` Gao Xiang 2018-07-26 12:22 ` [PATCH 24/25] staging: erofs: introduce cached decompression Gao Xiang 2018-07-26 12:22 ` Gao Xiang 2018-07-26 12:22 ` [PATCH 25/25] staging: erofs: add a TODO and update MAINTAINERS for staging Gao Xiang 2018-07-26 12:22 ` Gao Xiang 2018-07-28 7:10 ` [PATCH] staging: erofs: fix a compile warning of Z_EROFS_VLE_VMAP_ONSTACK_PAGES Gao Xiang 2018-07-28 7:10 ` Gao Xiang 2018-07-28 10:43 ` Chao Yu 2018-07-28 10:43 ` Chao Yu 2018-07-29 5:34 ` [PATCH 1/2] staging: erofs: fix compile error without built-in decompression support Gao Xiang 2018-07-29 5:34 ` Gao Xiang 2018-07-29 5:37 ` [PATCH 2/2] staging: erofs: fix conditional uninitialized `pcn' in z_erofs_map_blocks_iter Gao Xiang 2018-07-29 5:37 ` Gao Xiang 2018-07-30 1:51 ` [PATCH] staging: erofs: use the wrapped PTR_ERR_OR_ZERO instead of open code Gao Xiang 2018-07-30 1:51 ` Gao Xiang 2018-07-30 6:58 ` Chao Yu 2018-07-30 6:58 ` Chao Yu 2018-08-01 6:38 ` [PATCH 1/2] staging: erofs: add the missing break in z_erofs_map_blocks_iter Gao Xiang 2018-08-01 6:38 ` Gao Xiang 2018-08-01 6:38 ` [PATCH 2/2] staging: erofs: remove a redundant marco in xattr Gao Xiang 2018-08-01 6:38 ` Gao Xiang 2018-08-01 9:02 ` [PATCH 1/2] staging: erofs: add the missing break in z_erofs_map_blocks_iter Dan Carpenter 2018-08-01 9:02 ` Dan Carpenter 2018-08-01 9:19 ` Gao Xiang 2018-08-01 9:19 ` Gao Xiang 2018-08-01 9:36 ` [PATCH RESEND " Gao Xiang 2018-08-01 9:36 ` Gao Xiang 2018-08-01 11:36 ` Dan Carpenter 2018-08-01 11:36 ` Dan Carpenter 2018-08-01 12:08 ` Gao Xiang 2018-08-01 12:08 ` Gao Xiang 2018-07-30 2:07 ` [PATCH 2/2] staging: erofs: fix conditional uninitialized `pcn' " Chao Yu 2018-07-30 2:07 ` Chao Yu 2018-07-30 2:07 ` [PATCH 1/2] staging: erofs: fix compile error without built-in decompression support Chao Yu 2018-07-30 2:07 ` Chao Yu 2018-07-30 2:32 ` Gao Xiang 2018-07-30 2:32 ` Gao Xiang 2018-07-30 3:07 ` Chao Yu 2018-07-30 3:07 ` Chao Yu 2018-07-30 3:55 ` Gao Xiang 2018-07-30 3:55 ` Gao Xiang 2018-07-30 3:34 ` [FOR INTERNAL REVIEW] [PATCH RESEND 1/3] staging: erofs: fix incorrect code in erofs_shrink_scan Gao Xiang 2018-07-30 3:34 ` [FOR INTERNAL REVIEW] [PATCH RESEND 2/3] staging: erofs: add 'erofs_' prefixes for try_to_free_(all_)cached_page(s) Gao Xiang 2018-07-30 6:57 ` Chao Yu 2018-07-30 3:34 ` [FOR INTERNAL REVIEW] [PATCH RESEND 3/3] staging: erofs: fix conditional uninitialized `pcn' in z_erofs_map_blocks_iter Gao Xiang 2018-07-30 6:56 ` [FOR INTERNAL REVIEW] [PATCH RESEND 1/3] staging: erofs: fix incorrect code in erofs_shrink_scan Chao Yu 2018-07-27 0:25 ` [PATCH 00/25] staging: erofs: introduce erofs file system Christian Kujau 2018-07-27 1:39 ` Gao Xiang [this message] 2018-07-27 1:39 ` Gao Xiang 2018-07-27 1:56 ` Gao Xiang 2018-07-27 1:56 ` Gao Xiang 2018-07-28 7:25 ` Greg Kroah-Hartman 2018-07-28 7:25 ` Greg Kroah-Hartman 2018-07-28 9:33 ` Gao Xiang 2018-07-28 9:33 ` Gao Xiang 2018-07-28 10:34 ` Chao Yu 2018-07-28 10:34 ` Chao Yu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bcb9e620-f73b-4dbc-630b-af925c3d8ebd@huawei.com \ --to=gaoxiang25@huawei.com \ --cc=linux-erofs@lists.ozlabs.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lists@nerdbynature.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.