linux-kernel - [PATCH 0/7] erofs: introduce long xattr name prefixes feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230407141710.113882-1-jefflexu@linux.alibaba.com>
Date:   Fri,  7 Apr 2023 22:17:03 +0800
From:   Jingbo Xu <jefflexu@...ux.alibaba.com>
To:     xiang@...nel.org, chao@...nel.org, huyue2@...lpad.com,
        linux-erofs@...ts.ozlabs.org
Cc:     linux-kernel@...r.kernel.org
Subject: [PATCH 0/7] erofs: introduce long xattr name prefixes feature

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

 fs/erofs/data.c     |  23 +++++----
 fs/erofs/dir.c      |   3 +-
 fs/erofs/erofs_fs.h |  20 +++++++-
 fs/erofs/internal.h |  20 ++++++--
 fs/erofs/namei.c    |   4 +-
 fs/erofs/super.c    |  42 +++++++++-------
 fs/erofs/xattr.c    | 116 +++++++++++++++++++++++++++++++++++++++++---
 fs/erofs/xattr.h    |   4 ++
 fs/erofs/zdata.c    |   4 +-
 9 files changed, 192 insertions(+), 44 deletions(-)

-- 
2.19.1.6.gb485710b