You don't, but that's why I was wondering about time limits. You have to have a cut off somewhere, but if you're checking the last few minutes of uberblocks that really should cope with a lot. It seems like a simple enough thing to implement, and if a pool still gets corrupted with these checks in place, you can absolutely, positively blame it on the hardware. :D
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? This could be as simple as a USB stick plugged into the server, a separate drive, or a network server. I guess even the ZIL device would work if it's separate hardware. But knowing the locations of the uberblocks would save yet more time should recovery be needed. On Fri, Feb 13, 2009 at 8:59 PM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > On Fri, 13 Feb 2009, Ross Smith wrote: > >> Thinking about this a bit more, you've given me an idea: Would it be >> worth ZFS occasionally reading previous uberblocks from the pool, just >> to check they are there and working ok? > > That sounds like a good idea. However, how do you know for sure that the > data returned is not returned from a volatile cache? If the hardware is > ignoring cache flush requests, then any data returned may be from a volatile > cache. > > Bob > ====================================== > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
