Re: [PATCH 2/8] erofs-utils: lib: prepare for later deferred work

[Gao Xiang <xiang@kernel.org>]

Hi Yifan,

On Tue, Apr 16, 2024 at 07:58:30PM +0800, Yifan Zhao wrote:
> 
> On 4/16/24 4:04 PM, Gao Xiang wrote:
> > From: Gao Xiang <hsiangkao@linux.alibaba.com>
> > 
> > Split out ordered metadata operations and add the following helpers:
> > 
> >   - erofs_mkfs_jobfn()
> > 
> >   - erofs_mkfs_go()
> > 
> > to handle these mkfs job items for multi-threadding support.
> > 
> > Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> > ---
> >   lib/inode.c | 68 +++++++++++++++++++++++++++++++++++++++++++++--------
> >   1 file changed, 58 insertions(+), 10 deletions(-)
> > 
> > diff --git a/lib/inode.c b/lib/inode.c
> > index 55969d9..8ef0604 100644
> > --- a/lib/inode.c
> > +++ b/lib/inode.c
> > @@ -1133,6 +1133,57 @@ static int erofs_mkfs_handle_nondirectory(struct erofs_inode *inode)
> >   	return 0;
> >   }
> > +enum erofs_mkfs_jobtype {	/* ordered job types */
> > +	EROFS_MKFS_JOB_NDIR,
> > +	EROFS_MKFS_JOB_DIR,
> > +	EROFS_MKFS_JOB_DIR_BH,
> > +};
> > +
> > +struct erofs_mkfs_jobitem {
> > +	enum erofs_mkfs_jobtype type;
> > +	union {
> > +		struct erofs_inode *inode;
> > +	} u;
> > +};
> > +
> > +static int erofs_mkfs_jobfn(struct erofs_mkfs_jobitem *item)
> > +{
> > +	struct erofs_inode *inode = item->u.inode;
> > +	int ret;
> > +
> > +	if (item->type == EROFS_MKFS_JOB_NDIR)
> > +		return erofs_mkfs_handle_nondirectory(inode);
> > +
> > +	if (item->type == EROFS_MKFS_JOB_DIR) {
> > +		ret = erofs_prepare_inode_buffer(inode);
> > +		if (ret)
> > +			return ret;
> > +		inode->bh->op = &erofs_skip_write_bhops;
> > +		if (IS_ROOT(inode))
> > +			erofs_fixup_meta_blkaddr(inode);
> 
> I think this 2 line above does not exist in the logic replaced by
> `erofs_mkfs_jobfn`, should it appear in this patch, or need further
> explanation in the commit msg?

Because erofs_fixup_meta_blkaddr() needs to be called
strictly after erofs_prepare_inode_buffer(root) is
done, which allocates on-disk inode so NID is also
meaningful then.

But you're right. This part is not quite good, let me
think more about it.

Thanks,
Gao Xiang

> 
> 
> Thanks,
> 
> Yifan Zhao