ZFS documentation lists snapshot limits on any single file system in a pool at
2**48 snaps, and that seems to logically imply that a snap on a file system
does not require an update to the pool’s currently active uberblock. That is
to say, that if we take a snapshot of a file system in a pool, and then make
any changes to that file system, the copy on write behavior induced by the
changes will stop at some synchronization point below the uberblock (presumably
at or below the DNODE that is the DSL directory for that file system).
In-place updates to a DNODE that has been allocated in a single sector sized
ZFS block can be considered atomic, since the sector write will either succeed
or fail totally, leaving either the old version or the new version, but not a
combination of the two. This seems sensible to me, but the description of
object sets beginning on page 26 of the ZFS On-Disk Specification, states that
the DNODE type DMU_OT_DNODE (the type of the DNODE that’s included in the 1KB
objset_phys_t structure) will have a data load of an array of DNODES allocated
in 128KB blocks, and the picture (Illustration 12 in the spec) shows these
blocks as containing 1024 DNODES. Since DNODES are 512 bytes, it would not be
possible to fit the 1024 DNODES depicted in the illustration and if DNODES did
live in such an array then they could not be atomically updated in-place. If
the blocks in question were actually filled with an array of block pointers
pointing to single sector sized blocks that each held a DNODE then this would
account for the 1024 entries per 128KB block shown, since block pointers are
128 bytes (not the 512 bytes of a DNODE), but in this case wouldn’t such 128KB
blocks be considered to be indirect block pointers, forcing the dn_nlevels
field shown in the object set DNODE at the top left of Illustration 12 to be 2,
instead of the 1 that’s there ? I’m further confused by the illustration’s
use of dotted lines to project the contents of a structure field (as seen in
the projection of the metadnode field of the objset_phys_t structure found at
the top of the picture) and arrows to represent pointers (as seen in the
projection of the block pointer array of the DMU-OT-DNODE type dnode, also at
the top of the picture), but the blocks pointed to by these block pointers seem
to actually contain instances of DNODES (as seen from the projection of one of
these instances in the lower part of the picture). Should this projection be
replaced by a pointer to the lower DNODE ?
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
