Lines Matching full:node

83 - *Tree Node Cache (TNC)*: an in-memory B+ tree that reflects the current FS
95 UBIFS Index & Tree Node Cache
102 information like node type, node length, a sequence number, etc. (see
104 and some less important node types like padding nodes which are used to pad
113 a special node called *master node* into UBI LEB 1 which always points to the
114 most recent root node of the UBIFS index. For recoverability, the master node
116 LEB 1 and 2 to get the current master node and from there get the location of
120 additional runtime attributes per node which are not persisted. One of these is
141 ``mkfs.ubifs``) and stored in the superblock node. The log area contains only
143 node is written whenever an index commit is performed. Reference nodes are
144 written on every journal update. Each reference node points to the position of
150 a commit is initiated. This also writes a commit start node so that during
151 mount, UBIFS will seek for the most recent commit start node and just replay
152 every reference node after that. Every reference node before the commit start
153 node will be ignored as they are already part of the on-flash index.
156 available to write the reference node and buds part of this entry. Then, the
157 reference node is written and afterwards the buds describing the file changes.
158 On replay, UBIFS will record every reference node and inspect the location of
230 will always write a new version of the index root node and the master node
258 updating and persisting changed parts from leaf node up to the root node
260 with a hash over each node's child nodes. As a result, the index basically also
264 from the leaf nodes up to the root node including the master node. This process
265 can be hooked to recompute the hash only for each changed node at the same time.
266 Whenever a file is read, UBIFS can verify the hashes from each leaf node up to
267 the root node to ensure the node's integrity.
269 To ensure the authenticity of the whole index, the UBIFS master node stores a
270 keyed hash (HMAC) over its own contents and a hash of the root node of the index
271 tree. As mentioned above, the master node is always written to the flash whenever
274 Using this approach only UBIFS index nodes and the master node are changed to
282                              |  Master Node  |
288                             |  Index Node #1    |
299             |  Index Node #2    |       |  Index Node #3    |
307                | Data Node |         | INO Node |  | DENT Node |
311            Figure 3: Coverage areas of index node hash and master node HMAC
320 atomically together with its respective node.
329 This is done by creating a continuous hash beginning from the commit start node
330 over the previous reference nodes, the current reference node, and the bud
332 between the bud nodes. This new node type contains a HMAC over the current state
334 authentication node. The tail of the journal which may not have a authentication
335 node cannot be authenticated and is skipped during journal replay.
364 The location of the log area is stored in the master node. Since the master
365 node is authenticated with a HMAC as described above, it is not possible to
367 the filesystem is created using `mkfs.ubifs` and stored in the superblock node.
369 the superblock struct. The superblock node is stored in LEB 0 and is only
376 The location of the LPT root node on the flash is stored in the UBIFS master
377 node. Since the LPT is written and read atomically on every commit, there is
380 node. Since the master node itself is authenticated, the LPTs authenticity can
381 be verified by verifying the authenticity of the master node and comparing the
391 superblock node. Further, it has to be available on mount of the filesystem
417 superblock node will additionally store a hash of the authentication key. This