linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "TJ Harrell" <tj@systemloc.com>
To: linux-raid@vger.kernel.org
Cc: systemloc@verizon.net
Subject: 2 failed disks RAID 5 behavior bug?
Date: Sun, 27 Jan 2008 14:44:09 -0500	[thread overview]
Message-ID: <000301c8611c$fdfcf090$f9f6d1b0$@com> (raw)
In-Reply-To: <18099.40761.348959.46664@notabene.brown>

Hi!

Let me apologize in advance for not having as much information as I'd like
to.

I have a RAID 5 array with 3 elements. Kernel is 2.6.23.

I had a SATA disk fail. On analysis, it's SMART claimed it had an
'electrical failure'. The drive sounded like an angry buzz-saw, so I'm
guessing more was going on with it. Anyway, when the drive failed,
/proc/mdstat showed two drives marked as failed [__U]. The other failed
drive was on the other channel of the same SATA controller. On inspection,
this second drive works fine. I'm guessing somehow the failing drive caused
the SATA controller to lock or something, which caused the RAID layer to
think the second drive was failed.

The problematic behavior is that once two elements were marked as failed,
any read or write access resulted in an "I/O Failure" message.
Unfortunately, I believe some writes were made to the array as the Event
Counter did not match on the two functional elements, and there was quite a
bit of data corruption of the superblock of the FS. 

I'm sorry I don't have more specifics, but I hope perhaps Mr. Brown or
someone else who knows the RAID code will consider making some sort of
safeguard to prevent writing to a RAID 5 array when more than one element is
failed.

PS: Please CC: me. :)

Thank You!
TJ Harrell
systemloc@verizon.net


      parent reply	other threads:[~2008-01-27 19:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-21 16:59 Need clarification on raid1 resync behavior with bitmap support Mike Snitzer
2007-07-23  7:21 ` Neil Brown
2007-07-23 12:47   ` Mike Snitzer
2007-08-03  6:42     ` Neil Brown
2007-08-03 13:41       ` Mike Snitzer
2007-08-03 21:33         ` Neil Brown
2007-08-06 15:30           ` Mike Snitzer
2007-08-10  5:15             ` Neil Brown
2008-01-27 19:44           ` TJ Harrell [this message]

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='000301c8611c$fdfcf090$f9f6d1b0$@com' \
    --to=tj@systemloc.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=systemloc@verizon.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).