On 04/15/09 14:30, Bob Friesenhahn wrote:
On Wed, 15 Apr 2009, Frank Middleton wrote:
zpool status shows errors after a pkg image-update
followed by a scrub.
If a corruption occured in the main memory, the backplane, or the disk
controller during the writes to these files, then the original data
written could be corrupted, even though you are using mirrors. If the
system experienced a physical shock, or power supply glitch, while the
data was written, then it could impact both drives.
Quite. Sounds like an architectural problem. This old machine probably
doesn't have ecc memory (AFAIK still rare on most PCs), but it is on
a serial UPS and isolated from shocks, and this has happened more
than once. These drives on this machine recently passed both the purge
and verify cycles (format/analyze) several times. Unless the data is
written to both drives from the same buffer and checksum (surely not!),
it is still unclear how it could get written to *both* drives with a
bad checksum. It looks like the files really are bad - neither of
them can be read - unless ZFS sensibly refuses to allow possibly good
files with bad checksums to be read (cannot read: I/O error).
BTW fmdump -ev doesn't seem to report any disk errors at all.
So my question remains - even with the grottiest hardware, how can
several files get written with bad checksums to mirrored drives? ZFS
has so many cool features this would be easy to live with if there
was a reasonably simple way to get copies of these files to restore
them, short of getting the source and recompiling, or pkg uninstall
followed by install (if you can figure out which pkg(s) the bad files
are in), but it seems to defeat the purpose of softwaremirroring...
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
