From: Bill Davidsen <davidsen@tmr.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: Sander Smeenk <ssmeenk@freshdot.net>, linux-raid@vger.kernel.org
Subject: Re: Data corruption on software raid.
Date: Sun, 18 Mar 2007 11:50:23 -0500 [thread overview]
Message-ID: <45FD6DCF.3040300@tmr.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0703180959090.32397@p34.internal.lan>
Justin Piszcz wrote:
>
>
> On Sun, 18 Mar 2007, Sander Smeenk wrote:
>
>> Hello! Long story. Get some coke.
>>
>> I'm having an odd problem with using software raid on two Western
>> Digital disks type WD2500JD-00F (250gb) connected to a Silicon Image
>> Sil3112 PCI SATA conroller running with Linux 2.6.20, mdadm 2.5.6
>
> [[ .. snip .. ]]
>
> See comments below.
>
> | Personalities : [raid1]
> | md0 : active raid1 hda2[0] hdb1[1]
> | 120060736 blocks [2/2] [UU]
Your comments below are thoughts on the PATA RAID1, not the one which is
giving trouble, the SATA. Unless you think that making the working array
faster, perhaps he's looking for ideas on fixing the array which isn't
working as expected.
>
> My main question:
>
> Why the 'heck' are you running a RAID1 with a master/slave
> combination? That is probably the -worst- way to run it. When using
> any form of RAID, make sure you do not share an IDE channel for any
> one raid device.
>
> Advice? Hook up each drive as a master, then your rebuild speed
> should go to 30-60MB/s.
>
> Traditional Troubleshooting:
>
> What does fdisk -l /dev/hda
> fdisk -l /dev/hdb
>
> Report?
>
> Also,
>
> What does:
>
> smartctl -a /dev/hda
> smartctl -a /dev/hdb
>
> show?
>
> Then,
>
> smartctl -t short /dev/hda
> smartctl -t short /dev/hdb
>
> Wait 5-10 minutes, re-run the commands (-a) above.
>
> Then,
>
> smartctl -t long /dev/hda
> smartctl -t long /dev/hdb
>
> Then re-run the (-a) smartctl above.
>
> --------
>
> Those errors look really weird, I would separate the two disks, each
> on their own IDE channel and see if your problem goes away.
>
> Justin.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2007-03-18 16:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-18 13:16 Data corruption on software raid Sander Smeenk
2007-03-18 14:02 ` Justin Piszcz
2007-03-18 16:50 ` Bill Davidsen [this message]
2007-03-18 17:38 ` Sander Smeenk
[not found] ` <45FD870C.3020403@tmr.com>
2007-03-18 22:00 ` Sander Smeenk
2007-03-18 15:17 ` Wolfgang Denk
2007-03-18 17:09 ` Bill Davidsen
2007-03-18 22:16 ` Neil Brown
2007-03-18 22:19 ` Neil Brown
-- strict thread matches above, loose matches on Subject: below --
2008-04-07 23:43 Data corruption on software RAID Mikulas Patocka
2008-04-08 10:22 ` Helge Hafting
2008-04-08 11:14 ` Mikulas Patocka
2008-04-09 18:33 ` Bill Davidsen
2008-04-10 3:07 ` Mikulas Patocka
2008-04-10 14:21 ` Bill Davidsen
2008-04-11 2:55 ` Mikulas Patocka
2008-04-10 6:14 ` Mario 'BitKoenig' Holbe
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=45FD6DCF.3040300@tmr.com \
--to=davidsen@tmr.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-raid@vger.kernel.org \
--cc=ssmeenk@freshdot.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).