OpenZFS Mastery is staggering along. Here we talk about how ZFS maintains uber-integrity.
Not having dedicated special index blocks sounds great, but every data tree needs a root. ZFS stores a pointer to the filesystem root in a special uberblock. Every pool has a queue of 128 uberblocks stored at algorithmically-predictable locations. In keeping with the copy-on-write design (Chapter XXX), uberblocks are never edited. Every time a new transaction group gets written to disk, ZFS records the new root information in the next uberblock in line. When the 128th uberblock is used, ZFS loops back to the beginning. At boot, the system searches for the uberblock with the highest transaction group number and uses that to find the pool’s root. If the newest uberblock appears damaged or incomplete, ZFS falls back to the newest usable uberblock. A badly timed failure might cost you the latest transaction group’s worth of data, but the pool itself will be coherent and will not require an integrity check.