From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Jingbo Xu <jefflexu@linux.alibaba.com>,
xiang@kernel.org, chao@kernel.org, huyue2@coolpad.com,
linux-erofs@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/7] erofs: introduce on-disk format for long xattr name prefixes
Date: Mon, 10 Apr 2023 13:24:15 +0800 [thread overview]
Message-ID: <d064267e-8ee6-4259-1cd3-3554b88ce662@linux.alibaba.com> (raw)
In-Reply-To: <20230407141710.113882-5-jefflexu@linux.alibaba.com>
On 2023/4/7 22:17, Jingbo Xu wrote:
> Besides the predefined xattr name prefixes, introduces long xattr name
> prefixes, which work similarly as the predefined name prefixes, except
> that they are user specified.
>
> It is especially useful for use cases together with overlayfs like
> Composefs model, which introduces diverse xattr values with only a few
> common xattr names (trusted.overlay.redirect, trusted.overlay.digest,
> and maybe more in the future). That makes the existing predefined
> prefixes ineffective in both image size and runtime performance.
>
> When a user specified long xattr name prefix is used, only the 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. All long xattr prefixes
> are stored in the packed or meta inode, which depends if fragments
> feature is enabled or not.
>
> For each long xattr name prefix, the on-disk format is kept as the same
> as the unique metadata format: ALIGN({__le16 len, data}, 4), where len
> represents the total size of struct erofs_xattr_long_prefix, followed
> by data of struct erofs_xattr_long_prefix itself.
>
> Each erofs_xattr_long_prefix keeps predefined prefixes (base_index)
> and the remaining prefix string without the trailing '\0'.
>
> Two fields are introduced to the on-disk superblock, where
> xattr_prefix_count represents the total number of the long xattr name
> prefixes recorded, and xattr_prefix_start represents the start offset of
> recorded name prefixes in the packed/meta inode divided by 4.
>
> When referring to a long xattr name prefix, the highest bit (bit 7) of
> erofs_xattr_entry.e_name_index is set, while the lower bits (bit 0-6)
> as a whole represents the index of the referred long name prefix among
> all long xattr name prefixes.
>
> Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Thanks,
Gao Xiang
> ---
> fs/erofs/erofs_fs.h | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/fs/erofs/erofs_fs.h b/fs/erofs/erofs_fs.h
> index 44876a97cabd..ea62f83dac40 100644
> --- a/fs/erofs/erofs_fs.h
> +++ b/fs/erofs/erofs_fs.h
> @@ -76,7 +76,8 @@ struct erofs_super_block {
> __le16 extra_devices; /* # of devices besides the primary device */
> __le16 devt_slotoff; /* startoff = devt_slotoff * devt_slotsize */
> __u8 dirblkbits; /* directory block size in bit shift */
> - __u8 reserved[5];
> + __u8 xattr_prefix_count; /* # of long xattr name prefixes */
> + __le32 xattr_prefix_start; /* start of long xattr prefixes */
> __le64 packed_nid; /* nid of the special packed inode */
> __u8 reserved2[24];
> };
> @@ -229,6 +230,13 @@ struct erofs_xattr_ibody_header {
> #define EROFS_XATTR_INDEX_LUSTRE 5
> #define EROFS_XATTR_INDEX_SECURITY 6
>
> +/*
> + * bit 7 of e_name_index is set when it refers to a long xattr name prefix,
> + * while the remained lower bits represent the index of the prefix.
> + */
> +#define EROFS_XATTR_LONG_PREFIX 0x80
> +#define EROFS_XATTR_LONG_PREFIX_MASK 0x7f
> +
> /* xattr entry (for both inline & shared xattrs) */
> struct erofs_xattr_entry {
> __u8 e_name_len; /* length of name */
> @@ -238,6 +246,12 @@ struct erofs_xattr_entry {
> char e_name[]; /* attribute name */
> };
>
> +/* long xattr name prefix */
> +struct erofs_xattr_long_prefix {
> + __u8 base_index; /* short xattr name prefix index */
> + char infix[]; /* infix apart from short prefix */
> +};
> +
> static inline unsigned int erofs_xattr_ibody_size(__le16 i_xattr_icount)
> {
> if (!i_xattr_icount)
next prev parent reply other threads:[~2023-04-10 5:27 UTC|newest]
Thread overview: 24+ 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-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-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 [this message]
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 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 18:22 ` kernel test robot
2023-04-07 22:28 ` [PATCH v2 " Jingbo Xu
2023-04-10 5:54 ` Gao Xiang
2023-04-16 14:24 ` [PATCH 0/7] erofs: introduce long xattr name prefixes feature Chao Yu
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=d064267e-8ee6-4259-1cd3-3554b88ce662@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®