From owner-freebsd-stable@FreeBSD.ORG  Fri Nov  9 11:47:17 2012
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: stable@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
 by hub.freebsd.org (Postfix) with ESMTP id D105E7A6
 for <stable@FreeBSD.org>; Fri,  9 Nov 2012 11:47:17 +0000 (UTC)
 (envelope-from lbc@bnrlabs.com)
Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [IPv6:2a01:e0c:1:1599::12])
 by mx1.freebsd.org (Postfix) with ESMTP id 11E798FC14
 for <stable@FreeBSD.org>; Fri,  9 Nov 2012 11:47:15 +0000 (UTC)
Received: from mail.bnrlabs.com (unknown [82.224.61.5])
 by smtp3-g21.free.fr (Postfix) with ESMTP id 44844A61EE;
 Fri,  9 Nov 2012 12:47:08 +0100 (CET)
Received: from [127.0.0.1] (unknown [172.20.96.112])
 by mail.bnrlabs.com (Postfix) with ESMTP id 07D3A46475;
 Fri,  9 Nov 2012 12:47:06 +0100 (CET)
Message-ID: <509CED3E.8090103@bnrlabs.com>
Date: Fri, 09 Nov 2012 12:47:10 +0100
From: "Lucas B. Cohen" <lbc@bnrlabs.com>
MIME-Version: 1.0
To: "H. Ingow" <hingow@gmail.com>
Subject: Re: smartctl question
References: <20121109111843.GA25461@tunchi>
In-Reply-To: <20121109111843.GA25461@tunchi>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: stable@FreeBSD.org
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2012 11:47:18 -0000

Hi,

On 2012.11.09 12:18, H. Ingow wrote:
> 
> Hi all,
> 
> one single disk in a zfs mirror failed permanently throwing errors like 
> kernel: (ada5:ata10:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 84
> (ICRC ABRT ) and alike.
>  
> The pool itself continued working degraded, smartctl showed a very high
> 199 UDMA_CRC_Error_Count value, which to my knowledge may indicate a
> broken cable, in this case indeed a  cable replacement  solved the
> problem, the pool resilvered and all is fine.
> 
> Still smartctl -a displays a value of 199 UDMA_CRC_Error_Count I reckon 
> to be way too high, though ( > 3900 ) .
> So is this value now including errors from previous broken cable ?

I'm pretty sure it is. I don't think SMART attributes can vary in value
both up and down ; they seem to me like they're counters that can only
get incremented.

> In other words, when, if at all, is the cache smartmontools read from
> flushed and values are to be taken as of the status after fixing a
> hardware problem but not swapping the disk ?
So, in my opinion no.