> Hi all,
> 
> on a x4500 with a relatively well patched Sol10u8
> 
> # uname -a
> SunOS s13 5.10 Generic_141445-09 i86pc i386 i86pc
> 
> I've started a scrub after about 2 weeks of operation
> and have a lot of 
> checksum errors:
> 
> s13:~# zpool status
>                                         
>                     
>                                         
> ced an unrecoverable error.  An
> attempt was made to correct the error.
>   Applications are unaffected.
> tion: 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
>                                   
> h17m, 8.96% done, 13h5m to go             
> config:
> 
> 
>         NAME          STATE     READ WRITE CKSUM
> atlashome     DEGRADED     0     0     0
>           raidz1      ONLINE       0     0     0
>   c0t0d0    ONLINE       0     0     0
>           c1t0d0    ONLINE       0     0     0
>   c5t0d0    ONLINE       0     0     0
>           c7t0d0    ONLINE       0     0     0
>   c8t0d0    ONLINE       0     0     0
>         raidz1      ONLINE       0     0     0
>     c0t1d0    ONLINE       0     0     0
>         c1t1d0    ONLINE       0     0     0
>     c5t1d0    ONLINE       0     0     0
>         c6t1d0    ONLINE       0     0     6
>     c7t1d0    ONLINE       0     0     0
>       raidz1      ONLINE       0     0     0
>       c8t1d0    ONLINE       0     0     0
>       c0t2d0    ONLINE       0     0     0
>       c1t2d0    ONLINE       0     0     0
>       c5t2d0    ONLINE       0     0     2
>       c6t2d0    ONLINE       0     0     1
>     raidz1      ONLINE       0     0     0
>         c7t2d0    ONLINE       0     0     0
>     c8t2d0    ONLINE       0     0     0
>         c0t3d0    ONLINE       0     0     0
>     c1t3d0    ONLINE       0     0     0
>         c5t3d0    ONLINE       0     0     0
>   raidz1      ONLINE       0     0     0
>           c6t3d0    ONLINE       0     0     0
>   c7t3d0    ONLINE       0     0     0
>           c8t3d0    ONLINE       0     0     0
>   c0t4d0    ONLINE       0     0     0
>           c1t4d0    ONLINE       0     0     0
> raidz1      ONLINE       0     0     0
>             c5t4d0    ONLINE       0     0     0
> c7t4d0    ONLINE       0     0     0
>             c8t4d0    ONLINE       0     0     0
> c0t5d0    ONLINE       0     0     1
>             c1t5d0    ONLINE       0     0     0
> idz1      ONLINE       0     0     0
>             c5t5d0    ONLINE       0     0     0
> c6t5d0    ONLINE       0     0     0
>             c7t5d0    ONLINE       0     0     0
> c8t5d0    ONLINE       0     0     1
>             c0t6d0    ONLINE       0     0     0
> idz1      DEGRADED     0     0     0
>             spare     DEGRADED     0     0     0
>   c1t6d0  DEGRADED     6     0    17  too many errors
> c8t7d0  ONLINE       0     0     0  11.8G
> resilvered
>             c5t6d0    ONLINE       0     0     0
> c6t6d0    ONLINE       0     0     0
>             c7t6d0    ONLINE       0     0     1
> c8t6d0    ONLINE       0     0     1
>           raidz1      ONLINE       0     0     0
>   c0t7d0    ONLINE       0     0     0
>           c1t7d0    ONLINE       0     0     1
>   c5t7d0    ONLINE       0     0     0
>           c6t7d0    ONLINE       0     0     0
>   c7t7d0    ONLINE       0     0     0
>       logs
>     c6t4d0      ONLINE       0     0     0
>     spares
>       c8t7d0      INUSE     currently in use
> ar, it seems that the pool survived it, but I'm a bit
> worried how to trace 
> down the problem of this.
> 
> Any suggestion how to proceed?
> 
> Cheers
> 
> Carsten
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discu
> ss

Hi Carsten,

Did anything about this configuration change before the checksum errors
occurred?

The errors on c1t6d0 are severe enough that your spare kicked in.

You can use the fmdump -eV command to review the disk errors that FMA has
detected. This command can generate a lot of output but you can see if
the checksum errors on the disks are transient or if they occur repeatedly.

At the very least, I would consider physically replacing c1t6d0.

Cindy
-- 
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to