Lines Matching refs:nodes
80 - *Index*: an on-flash B+ tree where the leaf nodes contain filesystem data
98 Basic on-flash UBIFS entities are called *nodes*. UBIFS knows different types
99 of nodes. Eg. data nodes (``struct ubifs_data_node``) which store chunks of file
100 contents or inode nodes (``struct ubifs_ino_node``) which represent VFS inodes.
101 Almost all types of nodes share a common header (``ubifs_ch``) containing basic
104 and some less important node types like padding nodes which are used to pad
108 as *wandering tree*, where only the changed nodes are re-written and previous
121 a dirty-flag which marks nodes that have to be persisted the next time the
126 on-flash filesystem structures like the index. On every commit, the TNC nodes
135 any changes (in form of inode nodes, data nodes etc.) between commits
142 two types of nodes: *reference nodes* and *commit start nodes*. A commit start
143 node is written whenever an index commit is performed. Reference nodes are
145 other nodes (inode nodes, data nodes etc.) on the flash that are part of this
146 journal entry. These nodes are called *buds* and describe the actual filesystem
181 Figure 2: UBIFS flash layout of log area with commit start nodes
182 (CS) and reference nodes (REF) pointing to main area
191 the LEB. The type is important, because UBIFS never mixes index nodes with data
192 nodes on a single LEB and thus each LEB has a specific purpose. This again is
259 of the full B+ tree. This enables us to augment the index nodes of the tree
260 with a hash over each node's child nodes. As a result, the index basically also
261 a Merkle tree. Since the leaf nodes of the index contain the actual filesystem
262 data, the hashes of their parent index nodes thus cover all the file contents
264 from the leaf nodes up to the root node including the master node. This process
274 Using this approach only UBIFS index nodes and the master node are changed to
275 include a hash. All other types of nodes will remain unchanged. This reduces
317 changed nodes are persisted is already designed for this purpose such that
319 hashes to index nodes does not change this since each hash will be persisted
330 over the previous reference nodes, the current reference node, and the bud
331 nodes. From time to time whenever it is suitable authentication nodes are added
332 between the bud nodes. This new node type contains a HMAC over the current state
359 Since the hash also includes the reference nodes an attacker cannot reorder or
360 skip any journal heads for replay. An attacker can only remove bud nodes or
361 reference nodes from the end of the journal, effectively rewinding the
378 no need to authenticate individual nodes of the tree. It suffices to
389 of superblock, master, commit start and reference nodes. This key has to be
392 to verify authenticated nodes and generate new HMACs for changes.