]>
Commit | Line | Data |
---|---|---|
962281a7 RK |
1 | NILFS2 |
2 | ------ | |
3 | ||
4 | NILFS2 is a log-structured file system (LFS) supporting continuous | |
5 | snapshotting. In addition to versioning capability of the entire file | |
6 | system, users can even restore files mistakenly overwritten or | |
7 | destroyed just a few seconds ago. Since NILFS2 can keep consistency | |
8 | like conventional LFS, it achieves quick recovery after system | |
9 | crashes. | |
10 | ||
11 | NILFS2 creates a number of checkpoints every few seconds or per | |
12 | synchronous write basis (unless there is no change). Users can select | |
13 | significant versions among continuously created checkpoints, and can | |
14 | change them into snapshots which will be preserved until they are | |
15 | changed back to checkpoints. | |
16 | ||
17 | There is no limit on the number of snapshots until the volume gets | |
18 | full. Each snapshot is mountable as a read-only file system | |
19 | concurrently with its writable mount, and this feature is convenient | |
20 | for online backup. | |
21 | ||
22 | The userland tools are included in nilfs-utils package, which is | |
23 | available from the following download page. At least "mkfs.nilfs2", | |
24 | "mount.nilfs2", "umount.nilfs2", and "nilfs_cleanerd" (so called | |
25 | cleaner or garbage collector) are required. Details on the tools are | |
26 | described in the man pages included in the package. | |
27 | ||
28 | Project web page: http://www.nilfs.org/en/ | |
29 | Download page: http://www.nilfs.org/en/download.html | |
30 | Git tree web page: http://www.nilfs.org/git/ | |
31 | NILFS mailing lists: http://www.nilfs.org/mailman/listinfo/users | |
32 | ||
33 | Caveats | |
34 | ======= | |
35 | ||
36 | Features which NILFS2 does not support yet: | |
37 | ||
38 | - atime | |
39 | - extended attributes | |
40 | - POSIX ACLs | |
41 | - quotas | |
fb6e7113 RK |
42 | - fsck |
43 | - resize | |
962281a7 RK |
44 | - defragmentation |
45 | ||
46 | Mount options | |
47 | ============= | |
48 | ||
49 | NILFS2 supports the following mount options: | |
50 | (*) == default | |
51 | ||
91f1953b | 52 | nobarrier Disables barriers. |
962281a7 RK |
53 | errors=continue(*) Keep going on a filesystem error. |
54 | errors=remount-ro Remount the filesystem read-only on an error. | |
55 | errors=panic Panic and halt the machine if an error occurs. | |
56 | cp=n Specify the checkpoint-number of the snapshot to be | |
57 | mounted. Checkpoints and snapshots are listed by lscp | |
58 | user command. Only the checkpoints marked as snapshot | |
59 | are mountable with this option. Snapshot is read-only, | |
60 | so a read-only mount option must be specified together. | |
61 | order=relaxed(*) Apply relaxed order semantics that allows modified data | |
62 | blocks to be written to disk without making a | |
63 | checkpoint if no metadata update is going. This mode | |
64 | is equivalent to the ordered data mode of the ext3 | |
65 | filesystem except for the updates on data blocks still | |
66 | conserve atomicity. This will improve synchronous | |
67 | write performance for overwriting. | |
68 | order=strict Apply strict in-order semantics that preserves sequence | |
69 | of all file operations including overwriting of data | |
70 | blocks. That means, it is guaranteed that no | |
71 | overtaking of events occurs in the recovered file | |
72 | system after a crash. | |
0234576d RK |
73 | norecovery Disable recovery of the filesystem on mount. |
74 | This disables every write access on the device for | |
75 | read-only mounts or snapshots. This option will fail | |
76 | for r/w mounts on an unclean volume. | |
962281a7 RK |
77 | |
78 | NILFS2 usage | |
79 | ============ | |
80 | ||
81 | To use nilfs2 as a local file system, simply: | |
82 | ||
83 | # mkfs -t nilfs2 /dev/block_device | |
84 | # mount -t nilfs2 /dev/block_device /dir | |
85 | ||
86 | This will also invoke the cleaner through the mount helper program | |
87 | (mount.nilfs2). | |
88 | ||
89 | Checkpoints and snapshots are managed by the following commands. | |
90 | Their manpages are included in the nilfs-utils package above. | |
91 | ||
92 | lscp list checkpoints or snapshots. | |
93 | mkcp make a checkpoint or a snapshot. | |
94 | chcp change an existing checkpoint to a snapshot or vice versa. | |
95 | rmcp invalidate specified checkpoint(s). | |
96 | ||
97 | To mount a snapshot, | |
98 | ||
99 | # mount -t nilfs2 -r -o cp=<cno> /dev/block_device /snap_dir | |
100 | ||
101 | where <cno> is the checkpoint number of the snapshot. | |
102 | ||
103 | To unmount the NILFS2 mount point or snapshot, simply: | |
104 | ||
105 | # umount /dir | |
106 | ||
107 | Then, the cleaner daemon is automatically shut down by the umount | |
108 | helper program (umount.nilfs2). | |
109 | ||
110 | Disk format | |
111 | =========== | |
112 | ||
113 | A nilfs2 volume is equally divided into a number of segments except | |
114 | for the super block (SB) and segment #0. A segment is the container | |
115 | of logs. Each log is composed of summary information blocks, payload | |
116 | blocks, and an optional super root block (SR): | |
117 | ||
118 | ______________________________________________________ | |
119 | | |SB| | Segment | Segment | Segment | ... | Segment | | | |
120 | |_|__|_|____0____|____1____|____2____|_____|____N____|_| | |
121 | 0 +1K +4K +8M +16M +24M +(8MB x N) | |
122 | . . (Typical offsets for 4KB-block) | |
123 | . . | |
124 | .______________________. | |
125 | | log | log |... | log | | |
126 | |__1__|__2__|____|__m__| | |
127 | . . | |
128 | . . | |
129 | . . | |
130 | .______________________________. | |
131 | | Summary | Payload blocks |SR| | |
132 | |_blocks__|_________________|__| | |
133 | ||
134 | The payload blocks are organized per file, and each file consists of | |
135 | data blocks and B-tree node blocks: | |
136 | ||
137 | |<--- File-A --->|<--- File-B --->| | |
138 | _______________________________________________________________ | |
139 | | Data blocks | B-tree blocks | Data blocks | B-tree blocks | ... | |
140 | _|_____________|_______________|_____________|_______________|_ | |
141 | ||
142 | ||
143 | Since only the modified blocks are written in the log, it may have | |
144 | files without data blocks or B-tree node blocks. | |
145 | ||
146 | The organization of the blocks is recorded in the summary information | |
147 | blocks, which contains a header structure (nilfs_segment_summary), per | |
148 | file structures (nilfs_finfo), and per block structures (nilfs_binfo): | |
149 | ||
150 | _________________________________________________________________________ | |
151 | | Summary | finfo | binfo | ... | binfo | finfo | binfo | ... | binfo |... | |
152 | |_blocks__|___A___|_(A,1)_|_____|(A,Na)_|___B___|_(B,1)_|_____|(B,Nb)_|___ | |
153 | ||
154 | ||
155 | The logs include regular files, directory files, symbolic link files | |
156 | and several meta data files. The mata data files are the files used | |
157 | to maintain file system meta data. The current version of NILFS2 uses | |
158 | the following meta data files: | |
159 | ||
160 | 1) Inode file (ifile) -- Stores on-disk inodes | |
161 | 2) Checkpoint file (cpfile) -- Stores checkpoints | |
162 | 3) Segment usage file (sufile) -- Stores allocation state of segments | |
163 | 4) Data address translation file -- Maps virtual block numbers to usual | |
164 | (DAT) block numbers. This file serves to | |
165 | make on-disk blocks relocatable. | |
962281a7 RK |
166 | |
167 | The following figure shows a typical organization of the logs: | |
168 | ||
169 | _________________________________________________________________________ | |
170 | | Summary | regular file | file | ... | ifile | cpfile | sufile | DAT |SR| | |
171 | |_blocks__|_or_directory_|_______|_____|_______|________|________|_____|__| | |
172 | ||
173 | ||
174 | To stride over segment boundaries, this sequence of files may be split | |
175 | into multiple logs. The sequence of logs that should be treated as | |
176 | logically one log, is delimited with flags marked in the segment | |
177 | summary. The recovery code of nilfs2 looks this boundary information | |
178 | to ensure atomicity of updates. | |
179 | ||
180 | The super root block is inserted for every checkpoints. It includes | |
181 | three special inodes, inodes for the DAT, cpfile, and sufile. Inodes | |
182 | of regular files, directories, symlinks and other special files, are | |
183 | included in the ifile. The inode of ifile itself is included in the | |
184 | corresponding checkpoint entry in the cpfile. Thus, the hierarchy | |
185 | among NILFS2 files can be depicted as follows: | |
186 | ||
187 | Super block (SB) | |
188 | | | |
189 | v | |
190 | Super root block (the latest cno=xx) | |
191 | |-- DAT | |
192 | |-- sufile | |
193 | `-- cpfile | |
194 | |-- ifile (cno=c1) | |
195 | |-- ifile (cno=c2) ---- file (ino=i1) | |
196 | : : |-- file (ino=i2) | |
197 | `-- ifile (cno=xx) |-- file (ino=i3) | |
198 | : : | |
199 | `-- file (ino=yy) | |
200 | ( regular file, directory, or symlink ) | |
201 | ||
202 | For detail on the format of each file, please see include/linux/nilfs2_fs.h. |