All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yue Hu <zbestahu@163.com>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: xiang@kernel.org, yuchao0@huawei.com,
	linux-erofs@lists.ozlabs.org, huyue2@yulong.com
Subject: Re: [PATCH] erofs-utils: do not check ->idata_size for compressed files in erofs_prepare_inode_buffer()
Date: Tue, 31 Aug 2021 17:00:29 +0800	[thread overview]
Message-ID: <20210831170029.000015a2.zbestahu@163.com> (raw)
In-Reply-To: <20210617181350.000005e6.zbestahu@gmail.com>

On Thu, 17 Jun 2021 18:14:17 +0800
Yue Hu <zbestahu@gmail.com> wrote:

> On Thu, 17 Jun 2021 17:30:26 +0800
> Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> 
> > On Thu, Jun 17, 2021 at 05:27:33PM +0800, Gao Xiang wrote:  
> > > On Thu, Jun 17, 2021 at 05:15:55PM +0800, Yue Hu wrote:    
> > > > On Thu, 17 Jun 2021 17:04:29 +0800
> > > > Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> > > >     
> > > > > Hi Yue,
> > > > > 
> > > > > On Thu, Jun 17, 2021 at 04:29:54PM +0800, Yue Hu wrote:    
> > > > > > From: Yue Hu <huyue2@yulong.com>
> > > > > > 
> > > > > > erofs_write_compressed_file() will always set inode->idata_size = 0
> > > > > > if succeed, that means no tail-end data for compressed files. So, no
> > > > > > need to call erofs_prepare_tail_block() which is used to handle
> > > > > > tail-end data for that case. Just skip it.      
> > > > > 
> > > > > Thanks for the patch, due to somewhat long time so I don't quite
> > > > > remember the exact logic here now...
> > > > > 
> > > > > Yet from the description before, it's not strictly correct
> > > > > since my original intention would be to support tail-packing
> > > > > inline compressed data which is similar to uncompressed case
> > > > > to decrease tail extent I/O and save more space.    
> > > > 
> > > > nice.
> > > >     
> > > > > 
> > > > > BTW, if you have some interest, would you like to implement it? :)    
> > > > 
> > > > I don't know if i can finish it. But i would like to have a try :)    
> > > 
> > > My rough thought is to try to inline the last tail compresseed
> > > extent after the on-disk compressed extents, maybe we could let
> > > it work for non-compact (legacy) compress index format cases...    
> > 
> > I mean try to implement non-compact (legacy) compress index format cases
> > first.

I'm trying to do it under 4.19 code (since i have no 5.x environment temporarily).

Now, i think mkfs should be done. But, kernel side seems not working fine(no crash,
no decompression warning/bug). Only some files are working, others not. I'm sure i
can catch the inline data correctly via file dump. And I'm trying debug the issue.
Maybe i need more time to read/understand more decompression code related.

BTW, now i understand no need to go z_erofs_vle_work_xxx for inline part(cur-end)
, just go next_part after mapping as below, am i right? 

Thanks.
  
> 
> Ok, let me try to implement it.
> 
> Thanks.
> 
> >   
> > > 
> > > Yeah, if you have extra time and interest, more ideas / thoughts /
> > > discussions are always welcomed ;)
> > > 
> > > Thanks,
> > > Gao Xiang
> > > 
> > >     
> > > > 
> > > > Thanks.
> > > >     
> > > > > 
> > > > > Thanks,
> > > > > Gao Xiang
> > > > >     
> > > > > > 
> > > > > > Also, correct 'a inode' -> 'an inode'.
> > > > > > 
> > > > > > Signed-off-by: Yue Hu <huyue2@yulong.com>
> > > > > > ---
> > > > > >  lib/inode.c | 4 ++--
> > > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/lib/inode.c b/lib/inode.c
> > > > > > index b6108db..b5f66de 100644
> > > > > > --- a/lib/inode.c
> > > > > > +++ b/lib/inode.c
> > > > > > @@ -111,7 +111,7 @@ struct erofs_dentry *erofs_d_alloc(struct erofs_inode *parent,
> > > > > >  	return d;
> > > > > >  }
> > > > > >  
> > > > > > -/* allocate main data for a inode */
> > > > > > +/* allocate main data for an inode */
> > > > > >  static int __allocate_inode_bh_data(struct erofs_inode *inode,
> > > > > >  				    unsigned long nblocks)
> > > > > >  {
> > > > > > @@ -572,11 +572,11 @@ static int erofs_prepare_inode_buffer(struct erofs_inode *inode)
> > > > > >  		int ret;
> > > > > >  
> > > > > >  		inode->datalayout = EROFS_INODE_FLAT_PLAIN;
> > > > > > -noinline:
> > > > > >  		/* expend an extra block for tail-end data */
> > > > > >  		ret = erofs_prepare_tail_block(inode);
> > > > > >  		if (ret)
> > > > > >  			return ret;
> > > > > > +noinline:
> > > > > >  		bh = erofs_balloc(INODE, inodesize, 0, 0);
> > > > > >  		if (IS_ERR(bh))
> > > > > >  			return PTR_ERR(bh);
> > > > > > -- 
> > > > > > 1.9.1      



  reply	other threads:[~2021-08-31  9:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17  8:29 [PATCH] erofs-utils: do not check ->idata_size for compressed files in erofs_prepare_inode_buffer() Yue Hu
2021-06-17  9:04 ` Gao Xiang
2021-06-17  9:15   ` Yue Hu
2021-06-17  9:27     ` Gao Xiang
2021-06-17  9:30       ` Gao Xiang
2021-06-17 10:14         ` Yue Hu
2021-08-31  9:00           ` Yue Hu [this message]
2021-08-31 11:15             ` Gao Xiang
2021-08-31 11:56               ` Yue Hu
2021-08-31 12:20                 ` Gao Xiang
2021-09-01  2:20                   ` Yue Hu
2021-09-01  3:05                     ` Gao Xiang

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=20210831170029.000015a2.zbestahu@163.com \
    --to=zbestahu@163.com \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=huyue2@yulong.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=xiang@kernel.org \
    --cc=yuchao0@huawei.com \
    /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: link
Be 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.