Comments below... On Sep 12, 2010, at 2:56 PM, Warren Strange wrote: >> So we are clear, you are running VirtualBox on ZFS, >> rather than ZFS on VirtualBox? >> > > Correct > >> >> Bad power supply, HBA, cables, or other common cause. >> To help you determine the sort of corruption, for >> mirrored pools FMA will record >> the nature of the discrepancies. >> fmdump -eV >> will show a checksum error and the associated bitmap >> comparisons. > > Below are the errors reported from the two disks. Not sure if anything looks > suspicious (other than the obvious checksum error) > > Sep 10 2010 12:49:42.315641690 ereport.fs.zfs.checksum > nvlist version: 0 > class = ereport.fs.zfs.checksum > ena = 0x95816e82e2900401 > detector = (embedded nvlist) > nvlist version: 0 > version = 0x0 > scheme = zfs > pool = 0xf3cb5e110f2c88ec > vdev = 0x961d9b28c1440020 > (end detector) > > pool = tank > pool_guid = 0xf3cb5e110f2c88ec > pool_context = 0 > pool_failmode = wait > vdev_guid = 0x961d9b28c1440020 > vdev_type = disk > vdev_path = /dev/dsk/c8t5d0s0 > vdev_devid = id1,s...@sata_____wdc_wd15eads-00p_____wd-wcavu0351361/a > parent_guid = 0xdae51838a62627b9 > parent_type = mirror > zio_err = 50 > zio_offset = 0x1ef6813a00 > zio_size = 0x20000 > zio_objset = 0x10 > zio_object = 0x1402f > zio_level = 0 > zio_blkid = 0x76f > cksum_expected = 0x405288851d24 0x100655c808fa2072 0xa89d11a403482052 > 0xf1041fd6f838c6eb > cksum_actual = 0x40528884fd24 0x100655c803286072 0xa89d111c8af30052 > 0xf0fbe93b4f02c6eb > cksum_algorithm = fletcher4 > __ttl = 0x1 > __tod = 0x4c8a7dc6 0x12d04f5a > > Sep 10 2010 12:49:42.315641636 ereport.fs.zfs.checksum > nvlist version: 0 > class = ereport.fs.zfs.checksum > ena = 0x95816e82e2900401 > detector = (embedded nvlist) > nvlist version: 0 > version = 0x0 > scheme = zfs > pool = 0xf3cb5e110f2c88ec > vdev = 0x969570b704d5bff1 > (end detector) > > pool = tank > pool_guid = 0xf3cb5e110f2c88ec > pool_context = 0 > pool_failmode = wait > vdev_guid = 0x969570b704d5bff1 > vdev_type = disk > vdev_path = /dev/dsk/c8t4d0s0 > vdev_devid = id1,s...@sata_____st31500341as________________9vs3b4cp/a > parent_guid = 0xdae51838a62627b9 > parent_type = mirror > zio_err = 50 > zio_offset = 0x1ef6813a00 > zio_size = 0x20000 > zio_objset = 0x10 > zio_object = 0x1402f > zio_level = 0 > zio_blkid = 0x76f > cksum_expected = 0x405288851d24 0x100655c808fa2072 0xa89d11a403482052 > 0xf1041fd6f838c6eb > cksum_actual = 0x40528884fd24 0x100655c803286072 0xa89d111c8af30052 > 0xf0fbe93b4f02c6eb > cksum_algorithm = fletcher4 > __ttl = 0x1 > __tod = 0x4c8a7dc6 0x12d04f24
In the case where one side of the mirror is corrupted and the other is correct, then you will be shown the difference between the two, in the form of an abbreviated bitmap. In this case, the data on each side of the mirror is the same, with a large degree of confidence. So the source of the corruption is likely to be the same -- some common component: CPU, RAM, HBA, I/O path, etc. You can rule out the disks as suspects. With some additional experiments you can determine if the corruption occurred during the write or the read. -- richard -- OpenStorage Summit, October 25-27, Palo Alto, CA http://nexenta-summit2010.eventbrite.com Richard Elling rich...@nexenta.com +1-760-896-4422 Enterprise class storage for everyone www.nexenta.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
