From owner-freebsd-fs@FreeBSD.ORG Fri Jun 10 12:36:45 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A997B106564A for ; Fri, 10 Jun 2011 12:36:45 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4598A8FC0A for ; Fri, 10 Jun 2011 12:36:44 +0000 (UTC) Received: from HexaDeca64.dmpriest.net.uk (HPQuadro64.dmpriest.net.uk [62.13.130.30]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/Kp) with ESMTP id p5ACahVs040941 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 10 Jun 2011 13:36:43 +0100 (BST) Date: Fri, 10 Jun 2011 13:36:42 +0100 From: Karl Pielorz To: Jeremy Chadwick Message-ID: In-Reply-To: <20110610093318.GA39276@icarus.home.lan> References: <729A0755FAEF480774EEF4AB@HexaDeca64.dmpriest.net.uk> <20110610093318.GA39276@icarus.home.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-fs@freebsd.org Subject: Re: ZFS scrub 'repaired' pool with no chksum or read errors? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:36:45 -0000 --On 10 June 2011 02:33 -0700 Jeremy Chadwick wrote: > ZFS experts please correct me, but my experience with this has shown me > that the scrub itself found actual issues while analysing all data on > the entire pool -- more specifically, I believe READ/WRITE/CKSUM are > counters used for when errors are encountered during normal (read: > non-scrub) operations. It's been a while since I've seen this happen, > but have seen it on our Solaris 10 machines at my workplace. I've never > been sure what it means; possibly signs of "bit rot"? I'm reasonably sure (and all the documentation I've seen) seems to indicate that the checksum/read error columns reflect errors found during either normal operations - or scrubs... I've run ZFS on some pretty ropey systems during testing, and it certainly seemed to 'tick up' the errors during scrubs. > If you're worried about your disk (ada0), please provide output from > "smartctl -a /dev/ada0" and I'll be more than happy to review the output > and provide you with any insights. I do believe you when you say it > looks fine, but every model of disk is different in some regard. I'm not overly worried about the disk or the errors - more curious as to why they showed without ticking up anything in the error columns - unless it's not meant to. I can email you the smart output, but there's no pending reallocations, all the SMART parameters are well above their thresholds - additionally smartd hasn't noticed anything 'changing' on the drive to alert about - the drive itself is also reasonably 'new' (and there's no evidence of anything being thrown in syslog/dmesg). If I get time later I might offline the drive and run a long test on it - if that does anything weird & wonderful, I'll take you up on your offer, and email you :-) But like I said, I'm not overly concerned, more curious ;) -Kp