All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: stan@hardwarefreak.com
Cc: Matt Garman <matthew.garman@gmail.com>,
	linux-raid <linux-raid@vger.kernel.org>
Subject: Re: mdadm vs zfs for home server?
Date: Mon, 27 May 2013 19:50:25 -0400	[thread overview]
Message-ID: <51A3F141.9050505@turmel.org> (raw)
In-Reply-To: <51A3DF2B.7070200@hardwarefreak.com>

Hi all,

On 05/27/2013 06:33 PM, Stan Hoeppner wrote:

[trim /]

> WRT to scheduled scrubbing, I don't do it, I don't believe in it.  While
> it may give you some piece of mind, this simply puts extra wear on the
> drives.  RAID6 it is self healing, right, so why bother with scrubbing?
>  It's a self fulfilling prophecy kinda thing--the more you scrub, the
> more likely you are to need to scrub due to the wear of previous scrubs.
>  I don't do it any arrays.  It just wears the drives out quicker.

I'm going to go out on a limb here and disagree with Stan.  I do "check"
scrubs in lieu of SMART long self tests, on a weekly basis.  They both
read the entire drive--necessary to uncover "pending" sectors.  But a
check scrub will rewrite that pending sector to immediately turn it into
a relocation, if it cannot be fixed.  An enterprise drive's better error
rate (an order of magnitude better, from the specs I've read) reduces
the need to do any scrub, but if you are doing long self tests anyways,
you should scrub.

In my humble opinion, *relocations* are the key indicator of approaching
drive failure, and they won't happen if pending sectors don't get rewritten.

Arguably, if you want to be anal, one could analyze the error reports
from an long self test, and "scrub" just the sectors with errors.  I
find that to be an unnecessary complication.

Phil

  reply	other threads:[~2013-05-27 23:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-27 18:09 mdadm vs zfs for home server? Matt Garman
2013-05-27 19:02 ` Roy Sigurd Karlsbakk
2013-05-28 15:00   ` Matt Garman
2013-05-28 15:18     ` Jon Nelson
2013-05-27 19:20 ` Roman Mamedov
2013-05-27 22:33 ` Stan Hoeppner
2013-05-27 23:50   ` Phil Turmel [this message]
2013-05-28  5:12     ` Stan Hoeppner
2013-05-28 15:24   ` Matt Garman
2013-05-28 15:55     ` Ryan Wagoner
  -- strict thread matches above, loose matches on Subject: below --
2013-05-28  3:09 Ryan Wagoner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51A3F141.9050505@turmel.org \
    --to=philip@turmel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=matthew.garman@gmail.com \
    --cc=stan@hardwarefreak.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.