ZFS Kernel Panics with 32 and 64 bit versions of 8.3 and 9.0

Simon simon at optinet.com
Sun May 6 20:59:43 UTC 2012


I fully understand the concept behind ECC memory and why it is important
to use it in a server environment, especially with a filesystem like ZFS.
However, I think my entire point was missed. It appears there are simply too
many documented cases where entire pool becomes inaccessible due to
limited corruption. Most of the data is still intact but there is no way to recover
it. And there is no way to fix the limited inconsistencies which caused the entire
pool to become unimportable to begin with. Again, I'm okay with few corrupted
or missing files. I'm not okay with entire pool becoming inaccessible due to
limited corruption due to faulty memory or otherwise. There needs to be a way
to import a corrupted zpool and at very least to be able to read the remaining
intact data.

-Simon


On Sun, 6 May 2012 09:59:39 -0500 (CDT), Bob Friesenhahn wrote:

>On Sun, 6 May 2012, Simon wrote:

>>
>> Are you suggesting that if a disk sector goes bad or memory corrupts few blocks
>> of data, the entire zpool is gonna go bust? can the same occur with a ZRAID?
>> I thought the ZFS was designed to overcome all these issues to begin with. Is
>> this not the case?

>ZFS is designed to work with failing disks, but not failing memory. 
>It is recommended to use only systems with ECC memory.

>The OS itself (any OS!) is succeptible to crash/corruption due to 
>failing memory but without zfs's checksums, you might not be aware of 
>such corruptions or the crash might be more delayed.

>Bob
>-- 
>Bob Friesenhahn
>bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
>GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/





More information about the freebsd-fs mailing list