[Originally posted to indiana-discuss] On certain X86 machines there's a hardware/software glitch that causes odd transient checksum failures that always seem to affect the same files even if you replace them. This has been submitted as a bug:
Bug 11201 - Checksum failures on mirrored drives - now CR 6880994 P4 kernel/zfs Checksum failures on mirrored drives We have SPARC based ZFS servers where we keep a copy of this rpool so we can more easily replace the damaged files (usually system libraries). In addition, to check the validity of the zfs send stream of the ZFS server rpool, there's a copy of that as well. For good reasons there might be several rpools in this data pool at any given time. When the ZFS server is rebooted, it tries to update the boot archive of every rpool it can find, including the X86 archive, which fails because it's the wrong architecture. The ZFS server is currently at snv103, but the backup server has an additional disk with snv111b on it, which was recently updated to snv122. However, if you boot snv103 and then reboot, it will also update the snv122 boot archive, rendering snv122 unbootable. All versions up to and including snv122 exhibit this behavior. I'm not sure why updating the boot archive would do this, but surely this is a bug. Reboot should only update it's own archive, and not any ZFS archives at all if it is running from UFS. Before submitting a bug report, I thought I'd check here to see if a) if this is has already been reported, and b) if I have the terminology right. Thanks -- Frank _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
