All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: stan@hardwarefreak.com
Cc: Ivan Lezhnjov IV <ivan.lezhnjov.iv@gmail.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Running check and e2fsck simultaneously
Date: Mon, 11 Nov 2013 09:51:24 +1100	[thread overview]
Message-ID: <20131111095124.560dc6c0@notabene.brown> (raw)
In-Reply-To: <52800A73.9020401@hardwarefreak.com>

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

On Sun, 10 Nov 2013 16:36:35 -0600 Stan Hoeppner <stan@hardwarefreak.com>
wrote:

> On 11/10/2013 2:34 PM, NeilBrown wrote:
> > On Sun, 10 Nov 2013 13:17:21 -0600 Stan Hoeppner <stan@hardwarefreak.com>
> > wrote:
> > 
> >> Also, I see little/no value in running a scheduled mdadm check on a
> >> RAID1 array.  Any problems with RAID1 will be due to one of the disks
> >> beginning to fail in some mode, usually requiring sector relocation.
> > 
> > I think scrubbing has value on any RAID with redundancy.
> 
> That's a bit... redundant, Neil. :)

RAID0.  Sadly a name that is used, even though it is an oxymoron.

> 
> > The firmware can only relocate a sector if it reads it when it is marginal
> > but not yet completely lost.  If a sector is not read for a long time and
> > during that time the media degraded beyond recovery the firmware cannot do
> > anything.  But RAID1 can - it can get it from the other device.
> 
> But is a scrub required for this?  Isn't this exactly what occurs during
> normal operation with md/RAID1?  I.e. a read fails with disk error, so
> we grab the sector from the mirror?  So what advantage is there to
> scrubbing md/RAID1?
> 

If scrubbing finds and repairs a (rarely accessed) bad sector on one drive
before the other drive dies completely, that is a win.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2013-11-10 22:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-10 16:06 Running check and e2fsck simultaneously Ivan Lezhnjov IV
2013-11-10 18:08 ` Stan Hoeppner
2013-11-10 18:12   ` Ivan Lezhnjov IV
2013-11-10 19:17     ` Stan Hoeppner
2013-11-10 19:35       ` Ivan Lezhnjov IV
2013-11-10 20:12         ` Stan Hoeppner
2013-11-10 23:08           ` Ivan Lezhnjov IV
2013-11-11  3:43             ` Stan Hoeppner
2013-11-11  7:52               ` Ivan Lezhnjov IV
2013-11-11  8:09                 ` David Brown
2013-11-11  8:29                   ` Ivan Lezhnjov IV
2013-11-10 20:34       ` NeilBrown
2013-11-10 22:36         ` Stan Hoeppner
2013-11-10 22:51           ` NeilBrown [this message]
2013-11-10 22:54           ` Adam Goryachev
2013-11-11  2:08             ` Stan Hoeppner
2013-11-10 23:11         ` Ivan Lezhnjov IV

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=20131111095124.560dc6c0@notabene.brown \
    --to=neilb@suse.de \
    --cc=ivan.lezhnjov.iv@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --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.