>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!),
You really believe that the copy was copied and checksummed twice before
writing to the disk? Of course not. Copying the data doesn't help;
both pieces of memory need to be good. It's checksummed once. The
checksum fails to verify so:
- the memory was corrupted after the checksum was computed
- the data was damaged en route to the disk
- the data was damaged on disk.
- the data was damaged back from the disk
- the data was damaged in memory
>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).
That can happen when the memory is corrupted before the first write
to disk.
>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...
Bad memory.
Casper
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
