Difference between revisions of "Documentation/DnodeSync"

Jump to navigation Jump to search
Line 20: Line 20:


One of the first things you'll notice about a ''dnode_t'' (the in-memory representation of a dnode, which includes extra information that isn't stored on disk) is a collection of fields that start with ''dn_next_'' with size ''TXG_SIZE''. When I first started looking at this code that was a little confusing, so I'll explain it in brief here. At any one time, there can only be a certain number of transaction groups in existence (i.e. ''TXG_SIZE''). Because the contents of a dnode can be modified in each of those transaction groups, we need to store per-txg information in the dnode. Given a certain active TXG#, the info stored for that TXG can then be retrieved from an array with length TXG_SIZE at the element ''TXG# & TXG_SIZE''. For example, the ''dn_next_nlevels'' field stores any changes to the number of levels in the dnode tree.
One of the first things you'll notice about a ''dnode_t'' (the in-memory representation of a dnode, which includes extra information that isn't stored on disk) is a collection of fields that start with ''dn_next_'' with size ''TXG_SIZE''. When I first started looking at this code that was a little confusing, so I'll explain it in brief here. At any one time, there can only be a certain number of transaction groups in existence (i.e. ''TXG_SIZE''). Because the contents of a dnode can be modified in each of those transaction groups, we need to store per-txg information in the dnode. Given a certain active TXG#, the info stored for that TXG can then be retrieved from an array with length TXG_SIZE at the element ''TXG# & TXG_SIZE''. For example, the ''dn_next_nlevels'' field stores any changes to the number of levels in the dnode tree.
''dnode_sync'' starts by handling special cases, some of which use the ''dn_next_'' fields described in the previous paragraph. For example, if this is a newly allocated dnode being synced to disk (i.e. ''dn->dn_allocated_txg == tx->tx_txg'') then the ''dnode_phys_t'' object we'll be writing out must be populated with basic information on the type of the dnode, the number of levels, the blocks it has, etc. There are also special checks for changes in the block size of this dnode, the type, the length of the bonus buffer, or the type of the bonus buffer, among others.
The core of dnode_sync starts with a loop iterating over the ''dn_ranges'' for the current TXG.