Frank Middleton wrote:
Experimenting with OpenSolaris on an elderly PC with equally
elderly drives, zpool status shows errors after a pkg image-update
followed by a scrub. It is entirely possible that one of these
drives is flaky, but surely the whole point of a zfs mirror is
to avoid this? It seems unlikely that both drives failed at the
same time.
Possible causes:
+ bad CPU
+ bad memory, or memory which does not self-correct transient errors
+ faulty cabling
+ electrically noisy environment
+ multiply all of the above by 3 or more (main CPU, HBA, disk logic)
Alas, today we don't know if bad data was written to both
sides of the mirror. Rather, ZFS does not report if both sides
of the mirror agree, but the checksum fails. I filed an RFE on
this, because it would help diagnose where the corruption
occurred: memory/data path vs medium.
Could someone explain how this can happen? Another
question (perhaps for the indiana folks) is how to restore these
files?
These files look like they would have been delivered in an OS.
If so, just copy a good version over the bad.
-- richard
# zpool status -v
pool: rpool
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: scrub completed after 0h24m with 2 errors on Wed Apr 15
09:15:40 2009
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 69
mirror ONLINE 0 0 144
c3d0s0 ONLINE 0 0 145 128K repaired
c3d1s0 ONLINE 0 0 151 168K repaired
errors: Permanent errors have been detected in the following files:
//lib/amd64/libsec.so.1
//lib/libdlpi.so.1
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
