Difference between revisions of "Documentation/DnodeSync"

Jump to navigation Jump to search
1,085 bytes added ,  22:51, 7 October 2013
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 parts of the file into in-memory DMU buffers. Synchronizing these changes back out to disk at a time decided by ZFS is done in a dnode sync, from the function ''dnode_sync''.
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.
Editor
90

edits

Navigation menu