From what i understand, and from everything i've read by following threads
here, there are ways to do it but there is not a standardized tool yet, and
it's complicated and on a per-case basis but people who pay for support have
recovered pools.
i'm sure they are working on it, and i would imagine
So much for the it's a consumer hardware problem argument.
I for one gotta count it as a major drawback of ZFS that it doesn't provide you
a mechanism to get something of your pool back in the manner of reconstruction
or reversion, if a failure occurs, where there is a metadata inconsistency.
Thanks for following up with this, Russel.
On Jul 31, 2009, at 7:11 AM, Russel wrote:
After all the discussion here about VB, and all the finger pointing
I raised a bug on VB about flushing.
Remember I am using RAW disks via the SATA emulation in VB
the disks are WD 2TB drives. Also remember
Great to hear a few success stories! We have been experimentally
running ZFS on really crappy hardware and it has never lost a
pool. Running on VB with ZFS/iscsi raw disks we have yet to see
any errors at all. On sun4u with lsi sas/sata it is really rock
solid. And we've been going out of our way
I understand that the ZILs are allocated out of the general pool.
There is one intent log chain per dataset (file system or zvol).
The head of each log the log is kept in the main pool.
Without slog(s) we allocate (and chain) blocks from the
main pool. If separate intent log(s) exist then
On Fri, Jul 31, 2009 at 7:58 PM, Frank
Middletonf.middle...@apogeect.com wrote:
Has anyone ever actually lost a pool on Sun hardware other than
by losing too many replicas or operator error? As you have so
Yes, I have lost a pool when running on Sun hardware.
