Hi Richard,
Am 29.05.12 06:54, schrieb Richard Elling:
On May 28, 2012, at 9:21 PM, Stephan Budach wrote:
Hi all,
just to wrap this issue up: as FMA didn't report any other error than
the one which led to the degradation of the one mirror, I detached
the original drive from the zpool which flagged the mirror vdev as
ONLINE (although there was still a cksum error count of 23 on the
spare drive).
You showed the result of the FMA diagnosis, but not the error reports.
One feature of the error reports on modern Solaris is that the
expected and reported
bit images are described, showing the nature and extent of the corruption.
Are you referring to these errors:
root@solaris11c:~# fmdump -e -u f0601f5f-cb8b-67bc-bd63-e71948ea8428
TIME CLASS
Mai 27 10:24:23.3654 ereport.fs.zfs.checksum
Mai 27 10:24:23.3652 ereport.fs.zfs.checksum
Mai 27 10:24:23.3650 ereport.fs.zfs.checksum
Mai 27 10:24:23.3648 ereport.fs.zfs.checksum
Mai 27 10:24:23.3646 ereport.fs.zfs.checksum
Mai 27 10:24:23.2696 ereport.fs.zfs.checksum
Mai 27 10:24:23.2694 ereport.fs.zfs.checksum
Mai 27 10:24:23.2692 ereport.fs.zfs.checksum
Mai 27 10:24:23.2690 ereport.fs.zfs.checksum
Mai 27 10:24:23.2688 ereport.fs.zfs.checksum
Mai 27 10:24:23.2686 ereport.fs.zfs.checksum
And to pick one in detail:
root@solaris11c:~# fmdump -eV -u f0601f5f-cb8b-67bc-bd63-e71948ea8428
TIME CLASS
Mai 27 2012 10:24:23.365451280 ereport.fs.zfs.checksum
nvlist version: 0
class = ereport.fs.zfs.checksum
ena = 0xdfb23b0bc9700001
detector = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = zfs
pool = 0x855ebc6738ef6dd6
vdev = 0x52e3ca377dbdbec9
(end detector)
pool = obelixData
pool_guid = 0x855ebc6738ef6dd6
pool_context = 0
pool_failmode = wait
vdev_guid = 0x52e3ca377dbdbec9
vdev_type = disk
vdev_path = /dev/dsk/c9t2100001378AC02F4d9s0
vdev_devid = id1,sd@n2047001378ac02f4/a
parent_guid = 0x695bf14bdabd6714
parent_type = mirror
zio_err = 50
zio_offset = 0x2d8b974600
zio_size = 0x20000
zio_objset = 0x81ea9
zio_object = 0x5594
zio_level = 0
zio_blkid = 0x3c
cksum_expected = 0x12869460bd5d 0x49e4661395e6973
0xc974c2622ce7a035 0x81fe9ef14082a245
cksum_actual = 0x1bba2b185478 0x707883eac587dd3
0x54de998365cc6a8d 0x6822e5f4add45237
cksum_algorithm = fletcher4
bad_ranges = 0x0 0x20000
bad_ranges_min_gap = 0x8
bad_range_sets = 0x357a5
bad_range_clears = 0x3935b
bad_set_histogram = 0x8f3 0xdd4 0x52c 0x13d0 0xd76 0xea0 0xec1
0x100f 0x8f0 0xdc7 0x51e 0x13e7 0xd6b 0xe87 0xf30 0xf9c 0x8cd 0xddc
0x51a 0x1458 0xd93 0xf0a 0xf04 0x102d 0x8b4 0xdea 0x51a 0x141d 0xdd3
0xefc 0xf18 0x1003 0x8bc 0xde9 0x52f 0x13a4 0xdd9 0xf07 0xea2 0x100d
0x8c1 0xdf4 0x4e6 0x1368 0xdce 0xed9 0xf27 0x1002 0x8bf 0xdf4 0x4fe
0x1396 0xd7d 0xee0 0xf2b 0xfcc 0x8d8 0xdd7 0x4fc 0x13b8 0xd8e 0xe8b
0xedb 0x100e
bad_cleared_histogram = 0x0 0x46 0x211a 0xc77 0x124f 0x1146
0x113b 0x1020 0x0 0x35 0x20df 0xc9f 0x12dc 0x110c 0x10fc 0x1018 0x0 0x37
0x2103 0xcbb 0x12a9 0x113d 0x1100 0xf8d 0x0 0x35 0x210d 0xc6e 0x121a
0x1171 0x108f 0x1020 0x0 0x46 0x20ec 0xc3f 0x12ba 0x10ce 0x1172 0x1009
0x0 0x47 0x20a4 0xc5e 0x129f 0x1102 0x112e 0x1031 0x0 0x4a 0x20d1 0xc64
0x126b 0x1159 0x111c 0x1074 0x0 0x3a 0x20ed 0xc5b 0x1245 0x1160 0x111c 0xfc0
__ttl = 0x1
__tod = 0x4fc1e4b7 0x15c85810
They were all from the same vdev_path and ranged through these block IDs:
zio_blkid = 0x3c
zio_blkid = 0x3e
zio_blkid = 0x40
zio_blkid = 0x3a
zio_blkid = 0x3d
zio_blkid = 0xf
zio_blkid = 0xc
zio_blkid = 0x10
zio_blkid = 0x12
zio_blkid = 0x14
zio_blkid = 0x11
I really was a bit surprised by the cksum errors on the spare drive,
especially when no errors had been logged for the spare drive while it
was resilvering.
We'll see what the scrub will tell us.
Thanks,
budy
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
