All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Stumpf <mjstumpf@pobox.com>
To: linux-raid@vger.kernel.org
Subject: bit-rot, crc errors, etc question
Date: Thu, 06 Oct 2005 11:27:16 -0500	[thread overview]
Message-ID: <43455064.8020102@pobox.com> (raw)

Quick question:

Been running a large ext3 filesystem on an LVM set with multiple linux 
/dev/mdX raid5 arrays underneath.  Recently, upon trying to do full 
identical rewrites of every bit (literally) of data, I'm starting to 
find cases where the server locks up/reboots, and the culprit seems to 
be tracked to a first failure of one of the ATA drives having a bad 
CRC.  Replacing the single bad drive fixes the issue.

My best guess is this:  the filesystem is built on the LVM, composed of 
extents.  The extents reside on physical volumes.  The physical volumes 
are developing uncorrectable errors through natural use/time/heat/secret 
alien plot.  These silent failures sit around until I try to access 
those pieces of those drives, at which point big catastrophic failures 
occur, incurring downtime, potential data loss, and expense.

How can I 1) prevent this,  2) detect this,  3) correct this without 
tossing the drive for a single small bad area?

Is the md driver set smart enough to correct around such physical media 
errors?  Are there ways via mdadm/other tools to actively scan for such 
bad areas (obviously in this case filesystem tools to do this are 
useless, right)?  Can I potentially continue using this "bad" drive by 
somehow applying a correction?

Regards-
Michael Stumpf









             reply	other threads:[~2005-10-06 16:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-06 16:27 Michael Stumpf [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-10-06 18:21 bit-rot, crc errors, etc question Mike Hardy

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=43455064.8020102@pobox.com \
    --to=mjstumpf@pobox.com \
    --cc=linux-raid@vger.kernel.org \
    /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.