From: Bingwu Zhang <xtex@envs.net>
To: linux-erofs@lists.ozlabs.org
Cc: Gao Xiang <hsiangkao@linux.alibaba.com>
Subject: Re: Rebuild mode for tail-pack layouts
Date: Sat, 09 May 2026 16:37:43 +0800 [thread overview]
Message-ID: <CgjAP5WSSE2vLMZi0oabUw@envs.net> (raw)
In-Reply-To: <38546371-df53-4fa2-adf1-26ab2dd71542@linux.alibaba.com>
Hi,
On Monday, May 4, 2026 11:13:23 PM China Standard Time Gao Xiang wrote:
> Hi xtex,
>
> On 2026/4/30 20:09, xtex wrote:
> > Hi!
> >
> > In erofs_rebuild_write_blob_index (rebuild.c), only
> > EROFS_INODE_CHUNK_BASED
> > and FLAT_PLAIN are implemented, so when generating a metadata index with
> > rebuild mode, the sources cannot use tail-pack nor inline data layout.
> > However, disabling tail-packing can lead to great disk-space waste in many
> > cases, especially when the file-system consists of a lot of small files.
> >
> > Thus I attempted to implement FLAT_INLINE for it, only to realize that the
> > current chunk entry formats can only represent physical addresses that are
> > block-aligned while tail-pack extent is not.
> >
> > I wonder what do you think about adding a new chunk entry format? And how
> > should it be named?
> >
> > I would suggest the following structure:
> > struct erofs_inode_chunk_index_tp {
> >
> > __le16 startblk_hi; /* starting block number MSB */
> > __le16 device_id; /* back-end storage id (with bits masked)
> >
> > */
> >
> > __le32 startblk_lo; /* starting block number of this chunk */
> > /* new fields below */
> > __le16 startblk_off; /* starting block offset */
> > __le16 reserved;
> >
> > } __packed;
> > The 16b offset should be enough unless we are to support block size > 64K.
> > The reserved field is added for alignment.
>
> Sorry about the late response.
>
> Thanks for the question.
>
> FLAT_INLINE can be used for index rebuilding, which can work with
> uniaddr (or mapped_blkaddr) since the blkaddr will be mapped
> into the relative address based on the blob starting with
> mapped_blkaddr:
>
> https://erofs.docs.kernel.org/en/latest/ondisk/chunked_format.html#device-ta
> ble
>
> But I agree the expression in the page above is a bit
> ambigious through.
>
> Thanks,
> Gao Xiang
>
> > Best wishes.
Sorry for the late response and thanks for your answer.
I am sorry about that I didn't get it.
In __erofs_map_blocks:
> map->m_pa = erofs_pos(sbi, startblk);
and
> #define erofs_pos(sbi, nr) ((erofs_off_t)(nr) << (sbi)->blkszbits)
It seems like that the mapped PA is always block-aligned? However, the last
chunk of inline data is not?
Best wishes.
--
xtex (a.k.a. Bingwu Zhang) @ Sat, 09 May 2026 08:24:53 +0000
next prev parent reply other threads:[~2026-05-09 8:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 12:09 Rebuild mode for tail-pack layouts xtex
2026-05-04 15:13 ` Gao Xiang
2026-05-09 8:37 ` Bingwu Zhang [this message]
2026-05-09 10:03 ` Gao Xiang
2026-05-09 14:29 ` Bingwu Zhang
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=CgjAP5WSSE2vLMZi0oabUw@envs.net \
--to=xtex@envs.net \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
/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.