From owner-freebsd-fs@FreeBSD.ORG Mon Jun 7 13:31:25 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 91C68106567B for ; Mon, 7 Jun 2010 13:31:25 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2255D8FC1F for ; Mon, 7 Jun 2010 13:31:24 +0000 (UTC) Received: by fxm20 with SMTP id 20so2493393fxm.13 for ; Mon, 07 Jun 2010 06:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ElPHcB02FihrllgSxW0It4b4Wp1czmGJo0ZJDDmPOCo=; b=BwktnhfGURh89CjKAoSKAOPuNOuVIUuJGXLxwv+ufolJrPGV3qZHEYBj3pvVNsa3j7 Vo03yBYBd5OH7DSRDyhKbll+KqcW4GjO49lVRyTqtNZRELk8iSlZ/XG2kXBjtbsjidW3 i+PEuvMgM4gEfh1LAW097Rs+dJWYpgw5I/Dbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sWt6hnyzxlH9J/E2q4SXhgPqizkYfirbDxuW8qIyvzRNQehxHfcegEFbH7BwV26HT5 j5Ty4d28wkDM4soZBR00FuV7U4cOJWJ+qhMCSXFco9rNDoLXI0pw2XhauA5LFPKjgwa7 bo7QwBcNe3jRVVcagLPoGUq5FD0b7o3bmIxKs= MIME-Version: 1.0 Received: by 10.239.185.72 with SMTP id b8mr984872hbh.99.1275917483862; Mon, 07 Jun 2010 06:31:23 -0700 (PDT) Received: by 10.239.185.1 with HTTP; Mon, 7 Jun 2010 06:31:23 -0700 (PDT) In-Reply-To: <20100607121954.GA52932@icarus.home.lan> References: <4C0CAABA.2010506@icyb.net.ua> <20100607083428.GA48419@icarus.home.lan> <4C0CB3FC.8070001@icyb.net.ua> <20100607090850.GA49166@icarus.home.lan> <201006071112.o57BCGMf027496@higson.cam.lispworks.com> <20100607121954.GA52932@icarus.home.lan> Date: Mon, 7 Jun 2010 14:31:23 +0100 Message-ID: From: Tom Evans To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zfs i/o error, no driver error 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: Mon, 07 Jun 2010 13:31:25 -0000 On Mon, Jun 7, 2010 at 1:19 PM, Jeremy Chadwick wrote: > What's confusing about this is the phrase that pool verification is done > by "verifying all the blocks can be read". =C2=A0Doesn't that happen when= a > standard read operation comes down the pipe for a file? =C2=A0What I'm > getting at is that there's no explanation (that I can find) which states > why scrubbing regularly "ensures" anything, other than allowing a person > to see an error sooner than later. > The purpose is to avoid unrecoverable double failures. Assume you have a raidz, and you do not periodically scrub the disk. One of the disks develops a silent problem with reading a file. Later, a second disk completely fails. You replace the disk, and then during the resilver discover that your raidz is FAULTED, because it cannot reconstruct files from the silently dodgy first disk. With periodic scrubs, you are ensuring that at that point you can recover from a single disk failure. Regularly running a scrub increases your confidence that you will be able to recover. The ZFS best practices guide suggests a shorter interval for consumer grade hard drives because they have lower confidence in them to remain error free. As I understand it, the scrub is just an attempt to ensure that everything on the pool is readable, attempting to reconstruct it if there are any issues. I guess it is slightly more clever than 'find /tank -type f -print0 | xargs -0 cat > /dev/null'. Cheers Tom