All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schubert <bernd-schubert@web.de>
To: Martin Bene <martin.bene@icomedias.com>, linux-raid@vger.kernel.org
Subject: Re: Checking consistency of Linux software RAID
Date: Mon, 7 Jul 2003 20:29:14 +0200	[thread overview]
Message-ID: <200307072029.14998.bernd-schubert@web.de> (raw)
In-Reply-To: <4D618F6493CE064A844A5D496733D667031A01@freedom.icomedias.com>

On Monday 30 June 2003 14:58, Martin Bene wrote:
> Hi,
>
> Administrationg quite a few systems with HW raid controllers, I've come to
> really like a feature that seems to be missing from current SW raid:
>
> Scheduling a (weekly) complete media scan where all surfaces of all drives
> get read; in case of read errors a repair is tried: the content for the
> failed sector is reconstructed just as if the drive had completely failed
> and rewritten to the failed sector; if reading works afterwards, regard the
> repair as successfull and continue using the drive.
>
> Is there any way to do this with SW raid? I truly hate situations where
> some sectors on a drive fail silently and you don't notice until a 2nd
> drive dies and you find you can't recostruct your raid data becaus of
> silent "bitrot".
>

Hi,

/proc/mdstat is to monitor the status of your raid, so when one drive fails it 
becomes dropped out of the raid-array. Using mdadm you can monitor 
/proc/mdstat and it even can send you a mail when one of your disks fails. So 
if you really want to scan your disk once a week, why not running 'dd 
if=/dev/mdX of=/dev/zero' ? So every block of every raid-disk should become 
read and the md-driver should automatically drop a failing disk  out of the 
raid. 
I guess you could even try to repair a disk when it became dropped out of the 
raid by running some scripts, but since I never trusted any disk that had 
failed ones, I never worried about it.

Bernd

  parent reply	other threads:[~2003-07-07 18:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-30 12:58 Checking consistency of Linux software RAID Martin Bene
2003-06-30 13:13 ` Gordon Henderson
2003-06-30 13:16   ` Lars Marowsky-Bree
2003-06-30 13:28     ` Gordon Henderson
2003-06-30 13:36       ` Lars Marowsky-Bree
2003-06-30 13:16 ` Lars Marowsky-Bree
2003-07-07 18:29 ` Bernd Schubert [this message]
2003-07-07 18:42   ` Corey McGuire
2003-07-08 16:51     ` Bernd Schubert
2003-07-08 21:23       ` software raid hangs Donghui Wen
2003-07-08 21:38         ` Matt Simonsen
2003-07-08 21:41           ` Donghui Wen
2003-07-08 21:47       ` Checking consistency of Linux software RAID Corey McGuire
  -- strict thread matches above, loose matches on Subject: below --
2003-07-09  8:06 Martin Bene

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=200307072029.14998.bernd-schubert@web.de \
    --to=bernd-schubert@web.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=martin.bene@icomedias.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.