Lines Matching refs:the
11 Two superblocks exist at the beginning and end of the filesystem.
15 Superblock locations may differ for MTD and block devices. On MTD the
16 first non-bad block contains a superblock in the first 4096 Bytes and
17 the last non-bad block contains a superblock in the last 4096 Bytes.
18 On block devices, the first 4096 Bytes of the device contain the first
19 superblock and the last aligned 4096 Byte-block contains the second
22 For the most part, the superblocks can be considered read-only. They
23 are written only to correct errors detected within the superblocks,
24 move the journal and change the filesystem parameters through tunefs.
25 As a result, the superblock does not contain any fields that require
26 constant updates, like the amount of free space, etc.
31 The space in the device is split up into equal-sized segments.
32 Segments are the primary write unit of LogFS. Within each segments,
34 only a partial segment has been written, the segment number, the
36 the journal.
44 The journal contains all global information about the filesystem that
46 for the most recent commit entry, which contains a list of pointers to
52 All space except for the superblocks and journal is part of the object
54 objects, each consisting of the object header and the payload.
63 roughly according to the distance between the tree root and the data.
66 respectively. Inode file data is on level 6 for the inodes and 7-11
75 All inodes are stored in a special file, the inode file. Single
76 exception is the inode file's inode (master inode) which for obvious
77 reasons is stored in the journal instead. Instead of data blocks, the
78 leaf nodes of the inode files are inodes.
85 parent blocks are written as well, since the block pointers have
88 In LogFS, the block pointer changes are cached in the journal by means
91 the changed data. Any 8-byte word can be changes in this manner.
94 bytes and the height of an inodes indirect tree.
100 Initially, bad blocks are handled by moving the affected segment
101 content to a spare segment and noting this move in the journal with a
103 segment and the alias can be removed again. This is used on MTD only.
108 By cleverly predicting the life time of data, it is possible to
110 the GC overhead later. Each type of distinc life expectency (vim) can
121 A height field in the inode defines the height of the indirect tree
122 and thereby the indirection of the pointer.
124 Another difference is the addressing of indirect blocks. In LogFS,
125 the first 16 pointers in the first indirect block are left empty,
126 corresponding to the 16 direct pointers in the inode. In ext2 (maybe
127 others as well) the first pointer in the first indirect block
128 corresponds to logical block 12, skipping the 12 direct pointers.
138 accordingly. New inodes will inherit the compression flag of the
141 Metadata is always compressed. However, the space accounting ignores
142 this and charges for the uncompressed size. Failing to do so could
145 not consume any extra space, so the compression gains are lost space
146 to the user.
148 However, they are not lost space to the filesystem internals. By
149 cheating the user for those bytes, the filesystem gained some slack
155 Garbage collection is invoked whenever the number of free segments
157 on the least amount of valid data contained in the segment. All
165 lower than the active segments' erase counts, it will be picked. Wear
166 leveling is rate limited, so it will never monopolize the device for
176 located based on the hash. In order to both support large directories
178 tables of increasing size are used. For each table, the hash value
179 modulo the table size gives the table index.
181 Tables sizes are chosen to limit the number of indirect blocks with a
182 fully populated table to 0, 1, 2 or 3 respectively. So the first
183 table contains 16 entries, the second 512-16, etc.
186 the effective 32bit limit on telldir/seekdir cookies. Since logfs
187 uses the upper half of the address space for indirect blocks, the size
188 is limited to 2^31. Secondly the table contains hash buckets with 16
193 My math skills are insufficient to do the combinatorics for the 17x
195 10,000 runs the lowest directory fill before a bucket overflow was
220 Inodes are stored in the inode file, which is just a regular file for
221 most purposes. At umount time, however, the inode file needs to
224 complain about remaining inodes due to the inode file either. Same
225 goes for mapping inode of the device address space.
233 With compression, the block device (or mapping inode) cannot be used
235 logfs uses the top half of each inode's address space. The low 8TB
236 (on 32bit) are filled with file data, the high 8TB are used for
240 data in the top 8TB. But files >16TB would cause problems anyway, so
241 only the limit has changed.