All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Adam Goryachev <mailinglists@websitemanagers.com.au>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Running check and e2fsck simultaneously
Date: Sun, 10 Nov 2013 20:08:02 -0600	[thread overview]
Message-ID: <52803C02.1010201@hardwarefreak.com> (raw)
In-Reply-To: <52800E98.3080105@websitemanagers.com.au>

On 11/10/2013 4:54 PM, Adam Goryachev wrote:
> On 11/11/13 09:36, Stan Hoeppner wrote:
>> On 11/10/2013 2:34 PM, NeilBrown wrote:
>>> 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?
> Wouldn't a check of the raid cause each member to be read in full,
> therefore helping the disk to notice that the sector is marginal, and/or
> the RAID layer to notice that the sector is no longer readable and
> therefore read from the other member, and re-write the sector. Consider
> a sector that is very rarely accessed...
> 
> Or are you suggesting that a smart command issued to the underlying
> devices can solve both of those scenarios?

No, what I suggest is that drive instrumentation will often alert one to
drive problems before you see a read error at the kernel.  Assuming this
is true then scrubbing isn't necessary.

What Neil describes is a case where a sector is written once and read
very infrequently, or possibly years after the write, i.e. long term
archiving.  In this case a scrub may discover a media defect which may
go unnoticed by the drive firmware or normal md array operation.

-- 
Stan

  reply	other threads:[~2013-11-11  2:08 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
2013-11-10 22:54           ` Adam Goryachev
2013-11-11  2:08             ` Stan Hoeppner [this message]
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=52803C02.1010201@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=mailinglists@websitemanagers.com.au \
    /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.