On Mon, Dec 27, 2021 at 08:54:28PM +0800, Jeffle Xu wrote: > Until then erofs is exactly blockdev based filesystem. In other using > scenarios (e.g. container image), erofs needs to run upon files. > > This patch introduces a new nodev mode, in which erofs could be mounted > from a bootstrap blob file containing the complete erofs image. > > The following patch will introduce a new mount option "uuid", by which > users could specify the bootstrap blob file. > > Signed-off-by: Jeffle Xu <jefflexu@xxxxxxxxxxxxxxxxx> I think the order of some patches in this patchset can be improved. Take this patch as an example. This patch introduces a new mount option called "uuid", so the kernel will just accept it (which generates a user-visible impact) after this patch but it doesn't actually work. Therefore, we actually have three different behaviors here: - kernel doesn't support "uuid" mount option completely; - kernel support "uuid" but it doesn't work; - kernel support "uuid" correctly (maybe after some random patch); Actually that is bad for bisecting since there are some commits having temporary behaviors. And we don't know which commit actually fully implements this "uuid" mount option. So personally I think the proper order is just like the bottom-up approach, and make sure each patch can be tested / bisected independently. > --- > fs/erofs/data.c | 13 ++++++++--- > fs/erofs/internal.h | 1 + > fs/erofs/super.c | 56 +++++++++++++++++++++++++++++++++------------ > 3 files changed, 53 insertions(+), 17 deletions(-) > > diff --git a/fs/erofs/data.c b/fs/erofs/data.c > index 477aaff0c832..61fa431d0713 100644 > --- a/fs/erofs/data.c > +++ b/fs/erofs/data.c > @@ -11,11 +11,18 @@ > > struct page *erofs_get_meta_page(struct super_block *sb, erofs_blk_t blkaddr) > { > - struct address_space *const mapping = sb->s_bdev->bd_inode->i_mapping; > + struct address_space *mapping; > struct page *page; > > - page = read_cache_page_gfp(mapping, blkaddr, > - mapping_gfp_constraint(mapping, ~__GFP_FS)); Apart from the recommendation above, if my understanding is correct, I think after we implement fscache_aops, read_cache_page_gfp() can work with proper fscache mapping. So no need to implement something like erofs_readpage_from_fscache() later (at least for the case here.) Thanks, Gao Xiang > + if (sb->s_bdev) { > + mapping = sb->s_bdev->bd_inode->i_mapping; > + page = read_cache_page_gfp(mapping, blkaddr, > + mapping_gfp_constraint(mapping, ~__GFP_FS)); > + } else { > + /* TODO: data path in nodev mode */ > + page = ERR_PTR(-EINVAL); > + } > + -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs