|
1 | 1 | .. SPDX-License-Identifier: GPL-2.0
|
2 | 2 |
|
3 | 3 | ======================================
|
4 |
| -Enhanced Read-Only File System - EROFS |
| 4 | +EROFS - Enhanced Read-Only File System |
5 | 5 | ======================================
|
6 | 6 |
|
7 | 7 | Overview
|
8 | 8 | ========
|
9 | 9 |
|
10 |
| -EROFS file-system stands for Enhanced Read-Only File System. Different |
11 |
| -from other read-only file systems, it aims to be designed for flexibility, |
12 |
| -scalability, but be kept simple and high performance. |
| 10 | +EROFS filesystem stands for Enhanced Read-Only File System. It aims to form a |
| 11 | +generic read-only filesystem solution for various read-only use cases instead |
| 12 | +of just focusing on storage space saving without considering any side effects |
| 13 | +of runtime performance. |
13 | 14 |
|
14 |
| -It is designed as a better filesystem solution for the following scenarios: |
| 15 | +It is designed to meet the needs of flexibility, feature extendability and user |
| 16 | +payload friendly, etc. Apart from those, it is still kept as a simple |
| 17 | +random-access friendly high-performance filesystem to get rid of unneeded I/O |
| 18 | +amplification and memory-resident overhead compared to similar approaches. |
| 19 | + |
| 20 | +It is implemented to be a better choice for the following scenarios: |
15 | 21 |
|
16 | 22 | - read-only storage media or
|
17 | 23 |
|
18 | 24 | - part of a fully trusted read-only solution, which means it needs to be
|
19 | 25 | immutable and bit-for-bit identical to the official golden image for
|
20 |
| - their releases due to security and other considerations and |
| 26 | + their releases due to security or other considerations and |
21 | 27 |
|
22 | 28 | - hope to minimize extra storage space with guaranteed end-to-end performance
|
23 | 29 | by using compact layout, transparent file compression and direct access,
|
24 | 30 | especially for those embedded devices with limited memory and high-density
|
25 |
| - hosts with numerous containers; |
| 31 | + hosts with numerous containers. |
26 | 32 |
|
27 | 33 | Here is the main features of EROFS:
|
28 | 34 |
|
29 | 35 | - Little endian on-disk design;
|
30 | 36 |
|
31 |
| - - Currently 4KB block size (nobh) and therefore maximum 16TB address space; |
32 |
| - |
33 |
| - - Metadata & data could be mixed by design; |
| 37 | + - 4KiB block size and 32-bit block addresses, therefore 16TiB address space |
| 38 | + at most for now; |
34 | 39 |
|
35 |
| - - 2 inode versions for different requirements: |
| 40 | + - Two inode layouts for different requirements: |
36 | 41 |
|
37 |
| - ===================== ============ ===================================== |
| 42 | + ===================== ============ ====================================== |
38 | 43 | compact (v1) extended (v2)
|
39 |
| - ===================== ============ ===================================== |
| 44 | + ===================== ============ ====================================== |
40 | 45 | Inode metadata size 32 bytes 64 bytes
|
41 |
| - Max file size 4 GB 16 EB (also limited by max. vol size) |
| 46 | + Max file size 4 GiB 16 EiB (also limited by max. vol size) |
42 | 47 | Max uids/gids 65536 4294967296
|
43 | 48 | Per-inode timestamp no yes (64 + 32-bit timestamp)
|
44 | 49 | Max hardlinks 65536 4294967296
|
45 |
| - Metadata reserved 4 bytes 14 bytes |
46 |
| - ===================== ============ ===================================== |
| 50 | + Metadata reserved 8 bytes 18 bytes |
| 51 | + ===================== ============ ====================================== |
| 52 | + |
| 53 | + - Metadata and data could be mixed as an option; |
47 | 54 |
|
48 | 55 | - Support extended attributes (xattrs) as an option;
|
49 | 56 |
|
50 |
| - - Support xattr inline and tail-end data inline for all files; |
| 57 | + - Support tailpacking data and xattr inline compared to byte-addressed |
| 58 | + unaligned metadata or smaller block size alternatives; |
51 | 59 |
|
52 | 60 | - Support POSIX.1e ACLs by using xattrs;
|
53 | 61 |
|
54 | 62 | - Support transparent data compression as an option:
|
55 |
| - LZ4 algorithm with the fixed-sized output compression for high performance; |
| 63 | + LZ4 and MicroLZMA algorithms can be used on a per-file basis; In addition, |
| 64 | + inplace decompression is also supported to avoid bounce compressed buffers |
| 65 | + and page cache thrashing. |
| 66 | + |
| 67 | + - Support direct I/O on uncompressed files to avoid double caching for loop |
| 68 | + devices; |
56 | 69 |
|
57 |
| - - Multiple device support for multi-layer container images. |
| 70 | + - Support FSDAX on uncompressed images for secure containers and ramdisks in |
| 71 | + order to get rid of unnecessary page cache. |
| 72 | + |
| 73 | + - Support multiple devices for multi blob container images; |
| 74 | + |
| 75 | + - Support file-based on-demand loading with the Fscache infrastructure. |
58 | 76 |
|
59 | 77 | The following git tree provides the file system user-space tools under
|
60 |
| -development (ex, formatting tool mkfs.erofs): |
| 78 | +development, such as a formatting tool (mkfs.erofs), an on-disk consistency & |
| 79 | +compatibility checking tool (fsck.erofs), and a debugging tool (dump.erofs): |
61 | 80 |
|
62 | 81 | - git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git
|
63 | 82 |
|
@@ -91,6 +110,7 @@ dax={always,never} Use direct access (no page cache). See
|
91 | 110 | Documentation/filesystems/dax.rst.
|
92 | 111 | dax A legacy option which is an alias for ``dax=always``.
|
93 | 112 | device=%s Specify a path to an extra device to be used together.
|
| 113 | +fsid=%s Specify a filesystem image ID for Fscache back-end. |
94 | 114 | =================== =========================================================
|
95 | 115 |
|
96 | 116 | Sysfs Entries
|
@@ -226,8 +246,8 @@ Note that apart from the offset of the first filename, nameoff0 also indicates
|
226 | 246 | the total number of directory entries in this block since it is no need to
|
227 | 247 | introduce another on-disk field at all.
|
228 | 248 |
|
229 |
| -Chunk-based file |
230 |
| ----------------- |
| 249 | +Chunk-based files |
| 250 | +----------------- |
231 | 251 | In order to support chunk-based data deduplication, a new inode data layout has
|
232 | 252 | been supported since Linux v5.15: Files are split in equal-sized data chunks
|
233 | 253 | with ``extents`` area of the inode metadata indicating how to get the chunk
|
|
0 commit comments