Skip to content

Commit 3048102

Browse files
lostjefflehsiangkao
authored andcommitted
erofs: update documentation
- update new features like bloom filter and DEFLATE. - add documentation for the long xattr name prefixes, which was landed upstream since v6.4. Signed-off-by: Jingbo Xu <[email protected]> Reviewed-by: Gao Xiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Gao Xiang <[email protected]>
1 parent f939aee commit 3048102

File tree

1 file changed

+37
-3
lines changed

1 file changed

+37
-3
lines changed

Documentation/filesystems/erofs.rst

Lines changed: 37 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -58,12 +58,14 @@ Here are the main features of EROFS:
5858

5959
- Support extended attributes as an option;
6060

61+
- Support a bloom filter that speeds up negative extended attribute lookups;
62+
6163
- Support POSIX.1e ACLs by using extended attributes;
6264

6365
- Support transparent data compression as an option:
64-
LZ4 and MicroLZMA algorithms can be used on a per-file basis; In addition,
65-
inplace decompression is also supported to avoid bounce compressed buffers
66-
and page cache thrashing.
66+
LZ4, MicroLZMA and DEFLATE algorithms can be used on a per-file basis; In
67+
addition, inplace decompression is also supported to avoid bounce compressed
68+
buffers and unnecessary page cache thrashing.
6769

6870
- Support chunk-based data deduplication and rolling-hash compressed data
6971
deduplication;
@@ -268,6 +270,38 @@ details.)
268270

269271
By the way, chunk-based files are all uncompressed for now.
270272

273+
Long extended attribute name prefixes
274+
-------------------------------------
275+
There are use cases where extended attributes with different values can have
276+
only a few common prefixes (such as overlayfs xattrs). The predefined prefixes
277+
work inefficiently in both image size and runtime performance in such cases.
278+
279+
The long xattr name prefixes feature is introduced to address this issue. The
280+
overall idea is that, apart from the existing predefined prefixes, the xattr
281+
entry could also refer to user-specified long xattr name prefixes, e.g.
282+
"trusted.overlay.".
283+
284+
When referring to a long xattr name prefix, the highest bit (bit 7) of
285+
erofs_xattr_entry.e_name_index is set, while the lower bits (bit 0-6) as a whole
286+
represent the index of the referred long name prefix among all long name
287+
prefixes. Therefore, only the trailing part of the name apart from the long
288+
xattr name prefix is stored in erofs_xattr_entry.e_name, which could be empty if
289+
the full xattr name matches exactly as its long xattr name prefix.
290+
291+
All long xattr prefixes are stored one by one in the packed inode as long as
292+
the packed inode is valid, or in the meta inode otherwise. The
293+
xattr_prefix_count (of the on-disk superblock) indicates the total number of
294+
long xattr name prefixes, while (xattr_prefix_start * 4) indicates the start
295+
offset of long name prefixes in the packed/meta inode. Note that, long extended
296+
attribute name prefixes are disabled if xattr_prefix_count is 0.
297+
298+
Each long name prefix is stored in the format: ALIGN({__le16 len, data}, 4),
299+
where len represents the total size of the data part. The data part is actually
300+
represented by 'struct erofs_xattr_long_prefix', where base_index represents the
301+
index of the predefined xattr name prefix, e.g. EROFS_XATTR_INDEX_TRUSTED for
302+
"trusted.overlay." long name prefix, while the infix string keeps the string
303+
after stripping the short prefix, e.g. "overlay." for the example above.
304+
271305
Data compression
272306
----------------
273307
EROFS implements fixed-sized output compression which generates fixed-sized

0 commit comments

Comments
 (0)