raid5 failure

2000-07-21 Thread Seth Vidal

Hi,
 We've been using the sw raid 5 support in linux for about 2-3 months now.
We've had good luck with it.

Until this week.

In this one week we've lost two drives on a 3 drive array. Completely
eliminating the array. We have good backups, made everynight, so the data
is safe. The problem is this: What could have caused these dual drive
failures?

One went out on saturday the next on the following friday. Complete death.

One drive won't detect anywhere anymore and its been RMA'd the other
detects and I'm currently mke2fs -c on the drive.

Could this be a powersupply failure?

What is it that would cause this sort of fault?
Additionally it appears like the ide drive that is the system's os disk is
also failing.

It gets lba and seek failures reptetively.

I'm 99.999% certain this has NOTHING to do with software but I'd love to
know at what to point the finger.

-sv







Re: speed and scaling

2000-07-21 Thread Dan Jones

Seth Vidal wrote:
> 
> Hi folks,
>  I have an odd question. Where I work we will, in the next year, be in a
> position to have to process about a terabyte or more of data. The data is
> probably going to be shipped on tapes to us but then it needs to be read
> from disks and analyzed. The process is segmentable so its reasonable to
> be able to break it down into 2-4 sections for processing so arguably only
> 500gb per machine will be needed. I'd like to get the fastest possible
> access rates from a single machine to the data. Ideally 90MB/s+
> 
> So were considering the following:
> 
> Dual Processor P3 something.
> ~1gb ram.
> multiple 75gb ultra 160 drives - probably ibm's 10krpm drives

Something to think about regarding IBM 10K drives:

http://www8.zdnet.com/eweek/stories/general/0,11011,2573067,00.html

> Adaptec's best 160 controller that is supported by linux.
> 
> The data does not have to be redundant or stable - since it can be
> restored from tape at almost any time.
> 
> so I'd like to put this in a software raid 0 array for the speed.
> 
> So my questions are these:
>  Is 90MB/s a reasonable speed to be able to achieve in a raid0 array
> across say 5-8 drives?
> What controllers/drives should I be looking at?
> 
> And has anyone worked with gigabit connections to an array of this size
> for nfs access? What sort of speeds can I optimally (figuring nfsv3 in
> async mode from the 2.2 patches or 2.4 kernels) expect to achieve for
> network access.
> 
> thanks
> -sv

Lots of discussion on this already, so I will just touch on a few
points.

Jon Lewis mentioned that you should place a value on how long it
takes to read in your data sets when considering the value of RAID.
Unfortunately, RAID write throughput can be relatively slow for
HW RAID compared to SW RAID. I've appended some numbers for 
reference.

Also, the process of reading in from tape will double the load on
a single PCI bus. I think you will be happier with a dual PCI bus
MB. 

One of the the eternal unknowns is how well a particular Intel (or
clone) shipset will work for a particular I/O load. Alpha and Sparc
MB are designed with I/O as a higher priority goal than Intel MBs. 
Intel is getting better at this, but contention between the PCI 
busses for memory access can be a problem as well.

Brian Pomerantz at LLNL has gotten more than 90MB/s streaming to a
Ciprico RAID system, but he went to a fair amount of work to get 
there i.e. 2MB block sizes. You probably want to talk to him and 
you should be able to find post from him in the raid archives.



Hardware: dual PIII 600Mhz/Lancewood/128MB and 1GB
Mylex: 150, 1100, & 352
Mylex cache: writethru
Disks: 5 Atlas V

Some caveats:

1. The focus is on sequential performance. YMMV

2. The write number for SW RAID5 is surprisingly good. It either
indicates excellent cache managment and reuse of parity blocks or
some understanding of the sequential nature of the bonnie benchmark. 
A RAID5 update should be approximately 25% of raw write performance 
with no caching assistance. 

3. I am a little bothered by the very strong correlation between CPU% 
and MB/s for all of the Mylex controllers for the bonnie tests. I
guess that is the I/O service overhead, but it still seems high ot me.

4. The HW RAID numbers are for 5 drives. The SW RAID numbers are for
8 drives.

5. Effect of CPU memory on bonnie (AcceleRAID 150) read performance
is 15-20%. See below:


AcceleRAID 150 
DRAM=256MB
ReadWrite
BW MB/s CPU BW  CPU

RAID3   42.334%  4.6 3%

RAID5   43.038%  4.5 3%

RAID6(0+1)  37.533% 12.711%

DRAM=1GB
ReadWrite
BW MB/s CPU BW  CPU

RAID3   48.450%  4.6 3%

RAID5   49.151%  4.5 3%

RAID6(0+1)  45.239% 12.710%

6. The Mylex eXtremeRAID1100 does not show much difference in
   write performance between RAID5 and RAID6. See below:

-

ExtremeRAID 1100 1GB
ReadWrite
BW MB/s CPU BW  CPU

RAID3   48.350% 14.713%

RAID5   52.755% 15.113%

RAID6(0+1)  48.149% 14.7*   13%

RAID0   56.360% 40.837%

* This should be better
-

AcceleRAID 352  1GB
ReadWrite
BW MB/s CPU BW  CPU

RAID3   45.244%  6.8 5%

RAID5   46.245%  6.6 5%

RAID6(0+1)  39.639% 16.7*   14%

RAID0   50.550% 36.730%

* This is better


> 
> After talking to Dan Jones and the figures he was getting on Mylex cards, I
> decided to do some simple software raid benchmarks.
> 
> Hardware: dual PIII 500Mhz/Nightshade/128MB
> SCSI: NCR 53c895

Re: Is the raid1readbalance patch production ready?

2000-07-21 Thread Jakob Østergaard

On Fri, 21 Jul 2000, Malcolm Beattie wrote:

> Is the raid1readbalance-2.2.15-B2 patch (when applied against a
> 2.2.16+linux-2.2.16-raid-B2 kernel) rock-solid and production
> quality? Can I trust 750GB of users' email to it? Is it guaranteed
> to behave the same during failure modes that the non-patched RAID
> code does? Is anyone using it heavily in a production system?
> (Not that I expect any other answer except maybe for a resounding
> "probably" :-)

The patch only touches the read logic in the RAID code, and the patch
is fairly simple.  I've used the patch myself on a few busy systems
and had no problems what so ever.

Besides, I spent quite some time trying to improve the patch and come
up with a better approach  (I failed miserably though)  so I'm very
confident that Mika's patch is correct.  I've read it and understood
it, and I have no problem trusting it with my data.

-- 

: [EMAIL PROTECTED]  : And I see the elder races, :
:.: putrid forms of man:
:   Jakob Østergaard  : See him rise and claim the earth,  :
:OZ9ABN   : his downfall is at hand.   :
:.:{Konkhra}...:



Is the raid1readbalance patch production ready?

2000-07-21 Thread Malcolm Beattie

Is the raid1readbalance-2.2.15-B2 patch (when applied against a
2.2.16+linux-2.2.16-raid-B2 kernel) rock-solid and production
quality? Can I trust 750GB of users' email to it? Is it guaranteed
to behave the same during failure modes that the non-patched RAID
code does? Is anyone using it heavily in a production system?
(Not that I expect any other answer except maybe for a resounding
"probably" :-)

--Malcolm

-- 
Malcolm Beattie <[EMAIL PROTECTED]>
Unix Systems Programmer
Oxford University Computing Services



Re: raid5 troubles

2000-07-21 Thread Luca Berra

On Fri, Jul 21, 2000 at 11:17:18AM +0200, Martin Bene wrote:
> "dangerous" tools. Bzw, has anyone checked what's different in this tools
> package in comparison to the 19990824 release?

yes it raises the max number of devices per superblock!!!

-- 
Luca Berra -- [EMAIL PROTECTED]
Communication Media & Services S.r.l.



AW: raid5 troubles

2000-07-21 Thread Martin Bene

Hi Danilo,

> > [root@mrqserv2 linux]# mkraid /dev/md0
> > handling MD device /dev/md0
> > analyzing super-block
> > disk 0: /dev/sdb1, 4233096kB, raid superblock at 4233024kB
> > disk 1: /dev/sdc1, 4233096kB, raid superblock at 4233024kB
> > disk 2: /dev/sda6, failed
> > mkraid: aborted, see the syslog and /proc/mdstat for potential clues.
> > [root@mrqserv2 linux]#
> >
> > what is wrong here ?
>
> Most probably your version of raidtools-0.90 doesn't recognize the
> failed-disk directive. I use the version from Ingo's page (marked
> dangerous) http://people.redhat.com/mingo/raid-patches/... and it works
> fine.

Nope, "disk 2: /dev/sda6, failed" shows that mkraid definitely did recognice
the failed-disk directive; it's been in the official tools for quite some
time, the 19990824 tools definitely support it. no need to go for the
"dangerous" tools. Bzw, has anyone checked what's different in this tools
package in comparison to the 19990824 release?

Bye, Martin

PS: the problem was missing kernel patch.

"you have moved your mouse, please reboot to make this change take effect"
--
 Martin Bene   vox: +43-316-813824
 simon media   fax: +43-316-813824-6
 Andreas-Hofer-Platz 9 e-mail: [EMAIL PROTECTED]
 8010 Graz, Austria
--
finger [EMAIL PROTECTED] for PGP public key