Lines Matching full:nodes

76 - *Index*: an on-flash B+ tree where the leaf nodes contain filesystem data
94 Basic on-flash UBIFS entities are called *nodes*. UBIFS knows different types
95 of nodes. Eg. data nodes (`struct ubifs_data_node`) which store chunks of file
96 contents or inode nodes (`struct ubifs_ino_node`) which represent VFS inodes.
97 Almost all types of nodes share a common header (`ubifs_ch`) containing basic
100 and some less important node types like padding nodes which are used to pad
104 as *wandering tree*, where only the changed nodes are re-written and previous
117 a dirty-flag which marks nodes that have to be persisted the next time the
122 on-flash filesystem structures like the index. On every commit, the TNC nodes
131 any changes (in form of inode nodes, data nodes etc.) between commits
138 two types of nodes: *reference nodes* and *commit start nodes*. A commit start
139 node is written whenever an index commit is performed. Reference nodes are
141 other nodes (inode nodes, data nodes etc.) on the flash that are part of this
142 journal entry. These nodes are called *buds* and describe the actual filesystem
177                 Figure 2: UBIFS flash layout of log area with commit start nodes
178                           (CS) and reference nodes (REF) pointing to main area
187 the LEB. The type is important, because UBIFS never mixes index nodes with data
188 nodes on a single LEB and thus each LEB has a specific purpose. This again is
255 of the full B+ tree. This enables us to augment the index nodes of the tree
256 with a hash over each node's child nodes. As a result, the index basically also
257 a Merkle tree. Since the leaf nodes of the index contain the actual filesystem
258 data, the hashes of their parent index nodes thus cover all the file contents
260 from the leaf nodes up to the root node including the master node. This process
270 Using this approach only UBIFS index nodes and the master node are changed to
271 include a hash. All other types of nodes will remain unchanged. This reduces
313 changed nodes are persisted is already designed for this purpose such that
315 hashes to index nodes does not change this since each hash will be persisted
326 over the previous reference nodes, the current reference node, and the bud
327 nodes. From time to time whenever it is suitable authentication nodes are added
328 between the bud nodes. This new node type contains a HMAC over the current state
355 Since the hash also includes the reference nodes an attacker cannot reorder or
356 skip any journal heads for replay. An attacker can only remove bud nodes or
357 reference nodes from the end of the journal, effectively rewinding the
374 no need to authenticate individual nodes of the tree. It suffices to
385 of superblock, master, commit start and reference nodes. This key has to be
388 to verify authenticated nodes and generate new HMACs for changes.