Tim wrote:


On Fri, Feb 13, 2009 at 4:21 PM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us <mailto:bfrie...@simple.dallas.tx.us>> wrote:

    On Fri, 13 Feb 2009, Ross Smith wrote:

        However, I've just had another idea.  Since the uberblocks are
        pretty
        vital in recovering a pool, and I believe it's a fair bit of
        work to
        search the disk to find them.  Might it be a good idea to
        allow ZFS to
        store uberblock locations elsewhere for recovery purposes?


    Perhaps it is best to leave decisions on these issues to the ZFS
    designers who know how things work.

    Previous descriptions from people who do know how things work
    didn't make it sound very difficult to find the last 20
    uberblocks.  It sounded like they were at known points for any
    given pool.

    Those folks have surely tired of this discussion by now and are
    working on actual code rather than reading idle discussion between
    several people who don't know the details of how things work.



People who "don't know how things work" often aren't tied down by the baggage of knowing how things work. Which leads to creative solutions those who are weighed down didn't think of. I don't think it hurts in the least to throw out some ideas. If they aren't valid, it's not hard to ignore them and move on. It surely isn't a waste of anyone's time to spend 5 minutes reading a response and weighing if the idea is valid or not.

OTOH, anyone who followed this discussion the last few times, has looked
at the on-disk format documents, or reviewed the source code would know
that the uberblocks are kept in an 128-entry circular queue which is 4x
redundant with 2 copies each at the beginning and end of the vdev.
Other metadata, by default, is 2x redundant and spatially diverse.

Clearly, the failure mode being hashed out here has resulted in the defeat
of those protections. The only real question is how fast Jeff can roll out the
feature to allow reverting to previous uberblocks.  The procedure for doing
this by hand has long been known, and was posted on this forum -- though
it is tedious.
-- richard

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to