UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity

erofs: update documentation 

Some on-disk structures, fields have been renamed in v5.4,
the corresponding document should be updated as well.

Also fix misrespresentation of file time and words about
fixed-sized output compression, data inline, etc.

Link: https://lore.kernel.org/r/20191207025509.6614-1-hsiangkao@aol.com/
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
This commit is contained in:
Gao Xiang 2019-12-07 10:37:26 +08:00
parent 926d165017
commit ffafde4783
1 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
Documentation/filesystems/erofs.txt
View File

@ -24,11 +24,11 @@ Here is the main features of EROFS:
- Metadata & data could be mixed by design;
- 2 inode versions for different requirements:
v1 v2
compact (v1) extended (v2)
Inode metadata size: 32 bytes 64 bytes
Max file size: 4 GB 16 EB (also limited by max. vol size)
Max uids/gids: 65536 4294967296
File creation time: no yes (64 + 32-bit timestamp)
File change time: no yes (64 + 32-bit timestamp)
Max hardlinks: 65536 4294967296
Metadata reserved: 4 bytes 14 bytes
@ -39,7 +39,7 @@ Here is the main features of EROFS:
- Support POSIX.1e ACLs by using xattrs;
- Support transparent file compression as an option:
LZ4 algorithm with 4 KB fixed-output compression for high performance;
LZ4 algorithm with 4 KB fixed-sized output compression for high performance.
The following git tree provides the file system user-space tools under
development (ex, formatting tool mkfs.erofs):
@ -85,7 +85,7 @@ All data areas should be aligned with the block size, but metadata areas
may not. All metadatas can be now observed in two different spaces (views):
1. Inode metadata space
Each valid inode should be aligned with an inode slot, which is a fixed
value (32 bytes) and designed to be kept in line with v1 inode size.
value (32 bytes) and designed to be kept in line with compact inode size.
Each inode can be directly found with the following formula:
inode offset = meta_blkaddr * block_size + 32 * nid
@ -117,10 +117,10 @@ may not. All metadatas can be now observed in two different spaces (views):
|-> aligned with 4B
Inode could be 32 or 64 bytes, which can be distinguished from a common
field which all inode versions have -- i_advise:
field which all inode versions have -- i_format:
__________________ __________________
| i_advise | | i_advise |
| i_format | | i_format |
|__________________| |__________________|
| ... | | ... |
| | | |
@ -129,12 +129,13 @@ may not. All metadatas can be now observed in two different spaces (views):
|__________________| 64 bytes
Xattrs, extents, data inline are followed by the corresponding inode with
proper alignes, and they could be optional for different data mappings,
_currently_ there are totally 3 valid data mappings supported:
proper alignment, and they could be optional for different data mappings.
_currently_ total 4 valid data mappings are supported:
1) flat file data without data inline (no extent);
2) fixed-output size data compression (must have extents);
3) flat file data with tail-end data inline (no extent);
0 flat file data without data inline (no extent);
1 fixed-sized output data compression (with non-compacted indexes);
2 flat file data with tail packing data inline (no extent);
3 fixed-sized output data compression (with compacted indexes, v5.3+).
The size of the optional xattrs is indicated by i_xattr_count in inode
header. Large xattrs or xattrs shared by many different files can be
@ -182,8 +183,8 @@ introduce another on-disk field at all.
Compression
-----------
Currently, EROFS supports 4KB fixed-output clustersize transparent file
compression, as illustrated below:
Currently, EROFS supports 4KB fixed-sized output transparent file compression,
as illustrated below:
|---- Variant-Length Extent ----|-------- VLE --------|----- VLE -----
clusterofs clusterofs clusterofs