Thanks for the input Darren, but I'm still confused about DNODE atomicity ...
it's difficult to imagine that a change that is made anyplace in the zpool
would require copy operations all the way back up to the uberblock (e.g. if
some single file in one of many file systems in a zpool was suddenly changed,
making a new copy of all of the interceeding objects in the tree back to the
uberblock would seem to be an untenable amount of work even though it may all
be carried out in memory and not involve any IO, although if the zpool itself
was under snapshot control this would have to happen) ... the DNODE
implementation appears to include its own checksum field (self-checksumming),
and controlling
DNODEs (those that lead to decendent collections of DNODEs) are always of the
known type DMU_OT_DNODE and so their block pointers do not have to checksum the
DNODEs they point to (unlike all other block pointers that do cehcksum the data
they point to) ... this would allow for inplace updates of a DNODE, without the
need to continue further up the tree ... since all objects are controlled by a
DNODE, updates to an object's data can stop at its DNODE if that DNODE is not
under some snapshot or clone control ... if this is not the case, than 'any'
modification in the zpool would require copying up to the uberblock
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
