90
edits
Difference between revisions of "Documentation/DnodeSync"
Jump to navigation
Jump to search
→What is a dnode sync?
| Line 15: | Line 15: | ||
== What is a dnode sync? == | == What is a dnode sync? == | ||
To make changes to a ZFS object stored in a dnode (for example, a user file), ZFS reads | To make changes to a ZFS object stored in a dnode (for example, a user file), ZFS reads the necessary sections of the file into in-memory buffers (stored in a ''dmu_buf_impl_t'' object). Synchronizing these changes back out to disk is done in a dnode sync, from the function ''dnode_sync''. | ||
While this sounds like a simple process, it really isn't. The remainder of this article will attempt to give as accurate and comprehensive an overview of the actions required to sync a single dnode out to disk. | |||
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. | |||