> 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.
All commited changes (including snapshot creation) require a new uberblock to be written. > 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. There are no in-place updates. Any updates to a node would also require updating it's parent to make the checksum in that block consistent (and so on back up the tree). So instead a new block is written. -- 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
