On May 27, 2012, at 12:52 PM, Stephan Budach wrote:

> Hi, 
> 
> today I issued a scrub on one of my zpools and after some time I noticed that 
> one of the vdevs became degraded due to some drive having cksum errors. The 
> spare kicked in and the drive got resilvered, but why does the spare drive 
> now also show almost the same number of cksum errors, as the degraded drive?

The answer is not available via zpool status. You will need to look at the FMA 
diagnosis:
        fmadm faulty

more clues can be found in the FMA error reports:
        fmdump -eV

 -- richard


> 
> root@solaris11c:~# zpool status obelixData
>   pool: obelixData
>  state: DEGRADED
> status: One or more devices has experienced an unrecoverable error.  An
>         attempt was made to correct the error.  Applications are unaffected.
> action: Determine if the device needs to be replaced, and clear the errors
>         using 'zpool clear' or replace the device with 'zpool replace'.
>    see: http://www.sun.com/msg/ZFS-8000-9P
>   scan: resilvered 1,12T in 10h50m with 0 errors on Sun May 27 21:15:32 2012
> config:
> 
>         NAME                         STATE     READ WRITE CKSUM
>         obelixData                   DEGRADED     0     0     0
>           mirror-0                   ONLINE       0     0     0
>             c9t2100001378AC02DDd1    ONLINE       0     0     0
>             c9t2100001378AC02F4d1    ONLINE       0     0     0
>           mirror-1                   ONLINE       0     0     0
>             c9t2100001378AC02F4d0    ONLINE       0     0     0
>             c9t2100001378AC02DDd0    ONLINE       0     0     0
>           mirror-2                   ONLINE       0     0     0
>             c9t2100001378AC02DDd2    ONLINE       0     0     0
>             c9t2100001378AC02F4d2    ONLINE       0     0     0
>           mirror-3                   ONLINE       0     0     0
>             c9t2100001378AC02DDd3    ONLINE       0     0     0
>             c9t2100001378AC02F4d3    ONLINE       0     0     0
>           mirror-4                   ONLINE       0     0     0
>             c9t2100001378AC02DDd5    ONLINE       0     0     0
>             c9t2100001378AC02F4d5    ONLINE       0     0     0
>           mirror-5                   ONLINE       0     0     0
>             c9t2100001378AC02DDd4    ONLINE       0     0     0
>             c9t2100001378AC02F4d4    ONLINE       0     0     0
>           mirror-6                   ONLINE       0     0     0
>             c9t2100001378AC02DDd6    ONLINE       0     0     0
>             c9t2100001378AC02F4d6    ONLINE       0     0     0
>           mirror-7                   ONLINE       0     0     0
>             c9t2100001378AC02DDd7    ONLINE       0     0     0
>             c9t2100001378AC02F4d7    ONLINE       0     0     0
>           mirror-8                   ONLINE       0     0     0
>             c9t2100001378AC02DDd8    ONLINE       0     0     0
>             c9t2100001378AC02F4d8    ONLINE       0     0     0
>           mirror-9                   DEGRADED     0     0     0
>             c9t2100001378AC02DDd9    ONLINE       0     0     0
>             spare-1                  DEGRADED     0     0    10
>               c9t2100001378AC02F4d9  DEGRADED     0     0    22  too many 
> errors
>               c9t2100001378AC02BFd1  ONLINE       0     0    23
>           mirror-10                  ONLINE       0     0     0
>             c9t2100001378AC02DDd10   ONLINE       0     0     0
>             c9t2100001378AC02F4d10   ONLINE       0     0     0
>           mirror-11                  ONLINE       0     0     0
>             c9t2100001378AC02DDd11   ONLINE       0     0     0
>             c9t2100001378AC02F4d11   ONLINE       0     0     0
>           mirror-12                  ONLINE       0     0     0
>             c9t2100001378AC02DDd12   ONLINE       0     0     0
>             c9t2100001378AC02F4d12   ONLINE       0     0     0
>           mirror-13                  ONLINE       0     0     0
>             c9t2100001378AC02DDd13   ONLINE       0     0     0
>             c9t2100001378AC02F4d13   ONLINE       0     0     0
>           mirror-14                  ONLINE       0     0     0
>             c9t2100001378AC02DDd14   ONLINE       0     0     0
>             c9t2100001378AC02F4d14   ONLINE       0     0     0
>         logs
>           mirror-15                  ONLINE       0     0     0
>             c9t2100001378AC02D9d0    ONLINE       0     0     0
>             c9t2100001378AC02BFd0    ONLINE       0     0     0
>         spares
>           c9t2100001378AC02BFd1      INUSE     currently in use
> 
> 
> What would be the best way to proceed? The drive c9t2100001378AC02BFd1 is the 
> spare drive, that is tagged as ONLINE, but it shows 23 cksum errors, while 
> the drive that became degraded only shows 22 cksum errors.
> 
> What would be the best procedure to continue? Would one now first run another 
> scrub and detach the degraded drive afterwards, or detach the degrades drive 
> immediately and run a scrub afterwards?
> 
> Thanks,
> budy
> 
> 
> 
>  -- 
> Stephan Budach
> Jung von Matt/it-services GmbH
> Glashüttenstraße 79
> 20357 Hamburg
> 
> 
> Tel: +49 40-4321-1353
> Fax: +49 40-4321-1114
> E-Mail: stephan.bud...@jvm.de
> Internet: http://www.jvm.com
> 
> Geschäftsführer: Frank Wilhelm, Stephan Budach (stellv.)
> AG HH HRB 98380
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

--
ZFS Performance and Training
richard.ell...@richardelling.com
+1-760-896-4422







_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to