> 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)
How many objects need to change? Not that many. ... 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 I will have to go back and look at the dnode stuff in the specification. But everything I know about it suggests that any committed change to the filesystem structure (snapshots included) will require writing a new uberblock. Certainly the uberblock is updated periodically anyway. Perhaps someone knows an easy way to display the uberblock generation number so it can be viewed as changes are occuring? -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
