Date: Mon, 7 Jun 2010 14:31:23 +0100 From: Tom Evans <tevans.uk@googlemail.com> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-fs@freebsd.org Subject: Re: zfs i/o error, no driver error Message-ID: <AANLkTinkNKrSpy4LGNfGPVqiwA4NaRtFjEH7HCEFdjhu@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 7, 2010 at 1:19 PM, Jeremy Chadwick <freebsd@jdc.parodius.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinkNKrSpy4LGNfGPVqiwA4NaRtFjEH7HCEFdjhu>