From owner-freebsd-fs@FreeBSD.ORG Sat Jan 23 12:48:51 2010 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 3D144106566B for ; Sat, 23 Jan 2010 12:48:51 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id F0A0E8FC12 for ; Sat, 23 Jan 2010 12:48:50 +0000 (UTC) Received: by email.octopus.com.au (Postfix, from userid 1002) id 7A74F5CB90E; Sat, 23 Jan 2010 23:24:42 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: * X-Spam-Status: No, score=1.9 required=10.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.3 Received: from [10.20.30.101] (60.218.233.220.static.exetel.com.au [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 3CB1F5CB8E7; Sat, 23 Jan 2010 23:24:38 +1100 (EST) Message-ID: <4B5AF018.7070503@modulus.org> Date: Sat, 23 Jan 2010 23:48:24 +1100 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Rich , freebsd-fs@freebsd.org References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <4B5AE8D7.9000103@modulus.org> <5da0588e1001230443r1fee3b45o906690bc0115bb4e@mail.gmail.com> In-Reply-To: <5da0588e1001230443r1fee3b45o906690bc0115bb4e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Errors on a file on a zpool: How to remove? 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: Sat, 23 Jan 2010 12:48:51 -0000 Rich wrote: > zpool clear always clears the checksum column whenever I run it. > > Then, as soon as I touch those files again, or run a scrub, the > checksum error numbers tick up on those three disks, and those entries > appear in /var/log/messages. That is the normal behaviour if there are no additional copies of the data to go from (via mirroring or RAIDZ): it sees that the file has blocks with incorrect checksums, but it won't take action as there's no way to know if the file data is corrupt or the checksum value is wrong. You might be able to clear it by renaming the file and copying it back in place, and thus the new file will not have any bad checksums (but likely will contain corrupt data). - Andrew