Lines Matching full:node

79 - *Tree Node Cache (TNC)*: an in-memory B+ tree that reflects the current FS
91 UBIFS Index & Tree Node Cache
98 information like node type, node length, a sequence number, etc. (see
100 and some less important node types like padding nodes which are used to pad
109 a special node called *master node* into UBI LEB 1 which always points to the
110 most recent root node of the UBIFS index. For recoverability, the master node
112 LEB 1 and 2 to get the current master node and from there get the location of
116 additional runtime attributes per node which are not persisted. One of these is
137 ``mkfs.ubifs``) and stored in the superblock node. The log area contains only
139 node is written whenever an index commit is performed. Reference nodes are
140 written on every journal update. Each reference node points to the position of
146 a commit is initiated. This also writes a commit start node so that during
147 mount, UBIFS will seek for the most recent commit start node and just replay
148 every reference node after that. Every reference node before the commit start
149 node will be ignored as they are already part of the on-flash index.
152 available to write the reference node and buds part of this entry. Then, the
153 reference node is written and afterwards the buds describing the file changes.
154 On replay, UBIFS will record every reference node and inspect the location of
226 will always write a new version of the index root node and the master node
254 updating and persisting changed parts from leaf node up to the root node
256 with a hash over each node's child nodes. As a result, the index basically also
260 from the leaf nodes up to the root node including the master node. This process
261 can be hooked to recompute the hash only for each changed node at the same time.
262 Whenever a file is read, UBIFS can verify the hashes from each leaf node up to
263 the root node to ensure the node's integrity.
265 To ensure the authenticity of the whole index, the UBIFS master node stores a
266 keyed hash (HMAC) over its own contents and a hash of the root node of the index
267 tree. As mentioned above, the master node is always written to the flash whenever
270 Using this approach only UBIFS index nodes and the master node are changed to
278                              |  Master Node  |
284                             |  Index Node #1    |
295             |  Index Node #2    |       |  Index Node #3    |
303                | Data Node |         | INO Node |  | DENT Node |
307            Figure 3: Coverage areas of index node hash and master node HMAC
316 atomically together with its respective node.
325 This is done by creating a continuous hash beginning from the commit start node
326 over the previous reference nodes, the current reference node, and the bud
328 between the bud nodes. This new node type contains a HMAC over the current state
330 authentication node. The tail of the journal which may not have a authentication
331 node cannot be authenticated and is skipped during journal replay.
360 The location of the log area is stored in the master node. Since the master
361 node is authenticated with a HMAC as described above, it is not possible to
363 the filesystem is created using `mkfs.ubifs` and stored in the superblock node.
365 the superblock struct. The superblock node is stored in LEB 0 and is only
372 The location of the LPT root node on the flash is stored in the UBIFS master
373 node. Since the LPT is written and read atomically on every commit, there is
376 node. Since the master node itself is authenticated, the LPTs authenticity can
377 be verified by verifying the authenticity of the master node and comparing the
387 superblock node. Further, it has to be available on mount of the filesystem
413 superblock node will additionally store a hash of the authentication key. This