> FYI, I'm working on a workaround for broken devices. > As you note, > ome disks flat-out lie: you issue the > synchronize-cache command, > they say "got it, boss", yet the data is still not on > stable storage. > Why do they do this? Because "it performs better". > Well, duh -- > ou can make stuff *really* fast if it doesn't have to > be correct. >
> The uberblock ring buffer in ZFS gives us a way to > cope with this, > as long as we don't reuse freed blocks for a few > transaction groups. > The basic idea: if we can't read the pool startign > from the most > recent uberblock, then we should be able to use the > one before it, > or the one before that, etc, as long as we haven't > yet reused any > blocks that were freed in those earlier txgs. This > allows us to > use the normal load on the pool, plus the passage of > time, as a > displacement flush for disk caches that ignore the > sync command. > > If we go back far enough in (txg) time, we will > eventually find an > uberblock all of whose dependent data blocks have > make it to disk. > I'll run tests with known-broken disks to determine > how far back we > need to go in practice -- I'll bet one txg is almost > always enough. > > Jeff Hi Jeff, we just losed 2 pools on snv91. Any news about your workaround to recover pools discarding last txg? thanks gino -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
