Anton B. Rang wrote:
This might be impractical for a large file system, of course. It might be
easier to have a 'zscavenge' that would recover data, where possible, from a
corrupted file system. But there should be at least one of these. Losing a
whole pool due to the corruption of a couple of
Gino writes:
> > 6322646 ZFS should gracefully handle all devices
> > failing (when writing)
> >
> > Which is being worked on. Using a redundant
> > configuration prevents this
> > from happening.
>
> What do you mean with "redundant"? All our servers has 2 or 4 HBAs, 2 or 4
> fc swi
On Tue, Apr 10, 2007 at 09:43:39PM -0700, Anton B. Rang wrote:
>
> That's only one cause of panics.
>
> At least two of gino's panics appear due to corrupted space maps, for
> instance. I think there may also still be a case where a failure to
> read metadata during a transaction commit leads to
