Hi Fred,
Have you read the ZFS On Disk Format Specification paper
at:
http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf?
Ifred pam wrote:
Hi Richard, thanks for your time, I really appreciate it, but I'm still unclear
on how this works.
So uberblocks point to the MOS. Why do you then require multiple uberblocks? Or are there actually multiple MOS'es?
Or is there one MOS and multiple delta's to it (and its predecessors) and do the uberblocks then point to the latest delta?
In the latter case I can understand why Nullifying the latest uberblocks reverts to a previous
situation, otherwise I don't see the difference between "Nullifying the first uberblocks"
and "Nullifying the last uberblocks".
One reason for multiple uberblocks is that uberblocks, like everything
else, are copy-on-write.
The reason you have 4 copies (2 labels at front and 2 labels at the end
of every disk) is
redundancy. No, there are not multiple MOS'es in one pool (though
there may be multiple copies
of the MOS via "ditto" blocks). The current (or "active") uberblock is
the one with the highest
transaction id with valid checksum. Transaction ids are basically
monotonically increasing,
so nullifying the last uberblock can revert you to a previous state.
max
Thanks, Fred
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
