All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Jingbo Xu <jefflexu@linux.alibaba.com>,
	xiang@kernel.org, huyue2@coolpad.com,
	linux-erofs@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] erofs: introduce long xattr name prefixes feature
Date: Sun, 16 Apr 2023 22:24:13 +0800	[thread overview]
Message-ID: <815ed5d3-efae-9d18-b2b5-e56bb196ffda@kernel.org> (raw)
In-Reply-To: <20230407141710.113882-1-jefflexu@linux.alibaba.com>

On 2023/4/7 22:17, Jingbo Xu wrote:
> Background
> =========
> overlayfs uses xattrs to keep its own metadata.  If such xattrs are
> heavily used, such as Composefs model [1], large amount of xattrs
> with diverse xattr values exist but only a few common xattr names
> are valid (trusted.overlay.redirect, trusted.overlay.digest, and
> maybe more in the future) . For example:
> 
> # file 1
> trusted.overlay.redirect="xxx"
> 
> # file 2
> trusted.overlay.redirect="yyy"
> 
> That makes the existing predefined prefixes ineffective in both image
> size and runtime performance.
> 
> Solution Proposed
> ====================
> Let's introduce long xattr name prefixes now to fix this.  They work
> similarly as the predefined name prefixes, except that long xattr name
> prefixes are user specified.
> 
> When a long xattr name prefix is used, the shared long xattr prefixes
> are stored in the packed or meta inode, while the remained trailing part
> of the xattr name apart from the long xattr name prefix will be stored
> in erofs_xattr_entry.e_name.  e_name is empty if the xattr name matches
> exactly as the long xattr name prefix.
> 
> Erofs image sizes will be smaller in the above described scenario where
> all files have diverse xattr values with the same set of xattr names[2],
> such as having following xattrs like:
> 
> trusted.overlay.metacopy=""
> trusted.overlay.redirect="xxx"
> 
> Here are the image sizes for comparison (32-byte inodes are used):
> 
> ```
> 7.4M  large.erofs.T0.xattr
> 6.4M  large.erofs.T0.xattr.share
> ```
> 
> - share: "--xattr-prefix=trusted.overlay.redirect" option of mkfs.erofs.
> w/ this option, the long xattr name prefixes feature is enabled.
> 
> It can be seen ~14% disk space is saved with this feature in this
> typical workload, therefore metadata I/Os could also be more effective
> then.
> 
> Test
> ====
> It passes erofs/019 of erofs-utils.
> 
> 
> [1] https://lore.kernel.org/all/CAOQ4uxgGc33_QVBXMbQTnmbpHio4amv=W7ax2vQ1UMet0k_KoA@mail.gmail.com/
> [2] https://my.owndrive.com/index.php/s/irHJXRpZHtT3a5i
> 
> 
> 
> Gao Xiang (1):
>    erofs: keep meta inode into erofs_buf
> 
> Jingbo Xu (6):
>    erofs: initialize packed inode after root inode is assigned
>    erofs: move packed inode out of the compression part
>    erofs: introduce on-disk format for long xattr name prefixes
>    erofs: add helpers to load long xattr name prefixes
>    erofs: handle long xattr name prefixes properly
>    erofs: enable long extended attribute name prefixes

Acked-by: Chao Yu <chao@kernel.org>

Thanks,

      parent reply	other threads:[~2023-04-16 14:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-07 14:17 [PATCH 0/7] erofs: introduce long xattr name prefixes feature Jingbo Xu
2023-04-07 14:17 ` [PATCH 1/7] erofs: keep meta inode into erofs_buf Jingbo Xu
2023-04-07 14:17 ` [PATCH 2/7] erofs: initialize packed inode after root inode is assigned Jingbo Xu
2023-04-09 10:52   ` Gao Xiang
2023-04-10  2:44   ` Yue Hu
2023-04-10  2:44     ` Yue Hu
2023-04-07 14:17 ` [PATCH 3/7] erofs: move packed inode out of the compression part Jingbo Xu
2023-04-09 10:53   ` Gao Xiang
2023-04-10  2:45   ` Yue Hu
2023-04-10  2:45     ` Yue Hu
2023-04-07 14:17 ` [PATCH 4/7] erofs: introduce on-disk format for long xattr name prefixes Jingbo Xu
2023-04-10  5:24   ` Gao Xiang
2023-04-07 14:17 ` [PATCH 5/7] erofs: add helpers to load " Jingbo Xu
2023-04-10  5:44   ` Gao Xiang
2023-04-07 14:17 ` [PATCH 6/7] erofs: handle long xattr name prefixes properly Jingbo Xu
2023-04-10  5:53   ` Gao Xiang
2023-04-10  5:53     ` Gao Xiang
2023-04-10  6:39   ` [PATCH v2 " Jingbo Xu
2023-04-10  6:47     ` Gao Xiang
2023-04-11  9:35     ` [PATCH v3 " Jingbo Xu
2023-04-11  9:40       ` Gao Xiang
2023-04-07 14:17 ` [PATCH 7/7] erofs: enable long extended attribute name prefixes Jingbo Xu
2023-04-07 17:29   ` kernel test robot
2023-04-07 17:29     ` kernel test robot
2023-04-07 18:22   ` kernel test robot
2023-04-07 18:22     ` kernel test robot
2023-04-07 22:28   ` [PATCH v2 " Jingbo Xu
2023-04-10  5:54     ` Gao Xiang
2023-04-10  5:54       ` Gao Xiang
2023-04-16 14:24 ` Chao Yu [this message]

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=815ed5d3-efae-9d18-b2b5-e56bb196ffda@kernel.org \
    --to=chao@kernel.org \
    --cc=huyue2@coolpad.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xiang@kernel.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.