fsck'ing RAID's
What is the advice on whether to enable auto-fsck'ing in fstab on RAID5's? Seems redundant to have both fsck and raidsync run both at the same time and fsck seems to always find something amiss before resync'ing is completed. thanks cal
Re: performance limitations of linux raid
I find those numbers rather hard to believe. I've not yet heard of a disk (IDE or SCSI) that can reliably dump 22mb/sec which is what your 2 drive setup implies. Something isn't right. Check http://www.tomshardware.com , they review the Promise IDE RAID card (the hacked one for $30). They get some pretty insane throughputs on some ATA66 drives. Gee, they look pretty awesome, excellent performance. The only drawback i can think of is that it wouldnt be as flexible as software raid. I've been toying with the idea of getting one of those for a while, but there doesn't seem to be a linux driver for the FastTrack66 (the RAID card), only for the Ultra66 (the not-hacked IDE controller), and that driver has only 'Experimental' status with current production kernels: - snip --- CONFIG_BLK_DEV_PDC4030: This driver provides support for the secondary IDE interface and cache of Promise IDE chipsets, e.g. DC4030 and DC5030. This driver is known to incur timeouts/retries during heavy I/O to drives attached to the secondary interface. CDROM and TAPE devices are not supported yet. This driver is enabled at runtime using the "ide0=dc4030" kernel boot parameter. See the Documentation/ide.txt and drivers/block/pdc4030.c files for more info. - snap --- I even wrote to Promise to ask when or if a linux driver might become available, but didn't get much of an answer (they replied that there was a driver available for the Ultra, although I had specifically asked for the RAID card). If anyone hears about a Linux driver for this card, I'd like to know. Cheers, Frank -- frank joerdens joerdens new media heinrich-roller str. 16/17 10405 berlin germany e: [EMAIL PROTECTED] t: +49 (0)30 44055471 f: +49 (0)30 44055475 h: http://www.joerdens.de pgp public key: http://www.joerdens.de/pgp/frank_joerdens.asc
Re: performance limitations of linux raid
I find those numbers rather hard to believe. I've not yet heard of a disk (IDE or SCSI) that can reliably dump 22mb/sec which is what your 2 drive setup implies. Something isn't right. Sure it is. go to the ibm site and look at the specs on all the new high capacity drives. Without regard to the RPM, they are all spec'd to rip data off the drive at around 27mb/sec continuous. [EMAIL PROTECTED]
Re: Problems unmounting raid
I recently built a level 0 array out of 3 4.3G ultra DMA 66 ide drives. I have a Promise Ultra66 IDE controler in addition to the Ultra66 ide on the main board. Each drive is a master and the only drive on the cable. I am running 2.3.99-pre5 and have moved /usr to the array. This had been working fine for several weeks, but I have recently begun having problems unmounting /usr upon shutdown. I get errors that the file system is busy and the shutdown never completes. I end up givng the machine a hard reset or just power down. Does anyone know what may cause this poblem or have any suggestion I could try to track down the cause? sure, if you $ cd /usr/anything and leave it sitting there, the device will not umount, but will just say busy. The message is simply telling you that the device is "really" open, not just mounted. [EMAIL PROTECTED]
Re: performance limitations of linux raid
There's "specs" and then there's real life. I have never seen a hard drive that could do this. I've got brand new IBM 7200rpm ATA66 drives and I can't seem to get them to do much better than 6-7mb/sec with either Win98, Win2000, or Linux. That's with Abit BH6, an Asus P3C2000, and Supermicro PIIIDME boards. And yes, I'm using an 80 conductor cable. I'm using Wintune on the windows platforms and bonnie on Linux to do benchmarks. Cheers, Chris - Original Message - From: "Michael" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 24, 2000 5:10 PM Subject: Re: performance limitations of linux raid I find those numbers rather hard to believe. I've not yet heard of a disk (IDE or SCSI) that can reliably dump 22mb/sec which is what your 2 drive setup implies. Something isn't right. Sure it is. go to the ibm site and look at the specs on all the new high capacity drives. Without regard to the RPM, they are all spec'd to rip data off the drive at around 27mb/sec continuous. [EMAIL PROTECTED]
Re: performance limitations of linux raid
There's "specs" and then there's real life. I have never seen a hard drive that could do this. I've got brand new IBM 7200rpm ATA66 drives and I can't seem to get them to do much better than 6-7mb/sec with either Win98, Win2000, or Linux. That's with Abit BH6, an Asus P3C2000, and Supermicro PIIIDME boards. And yes, I'm using an 80 conductor cable. I'm using Wintune on the windows platforms and bonnie on Linux to do benchmarks. turn udma modes on in the bios and run hdparm -d 1 /dev/hda (where hda == drive device) the re-run your specs I think you'll find the speed is stepped up dramatically. i'm getting 16MB/s write and 22MB/s read on the same drive. I got for crap w/o the dma turned on via hdparm -sv
celeron vs k6-2
Hi folks, I did some tests comparing a k6-2 500 vs a celeron 400 - on a raid5 system - found some interesting results Raid5 write performance of the celeron is almost 50% better than the k6-2. Is this b/c of mmx (as james manning suggested) or b/c of the FPU? I used tiobench in sizes of than 3X my memory size on both systems - memory and drives of both systems were identical. Thanks -sv
RE: performance limitations of linux raid
-Original Message- From: Chris Mauritz [mailto:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 2:30 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: performance limitations of linux raid There's "specs" and then there's real life. I have never seen a hard drive that could do this. I've got brand new IBM 7200rpm ATA66 drives and I can't seem to get them to do much better than 6-7mb/sec with either Win98, Win2000, or Linux. That's with Abit BH6, an Asus P3C2000, and Supermicro PIIIDME boards. And yes, I'm using an 80 conductor cable. I'm using Wintune on the windows platforms and bonnie on Linux to do benchmarks. I don't believe the specs either, because they are for the "ideal" case. However, I think that either your benchmark is flawed, or you've got a crappy controller. I have a (I think) 5400 RPM 4.5GB IBM SCA SCSI drive in a machine at home, and I can easily read at 7MB/sec from it under Solaris. Linux is slower, but that's because of the drivers for the SCSI controller. I haven't done any benchmarks on my IDE drives because I already know that they're SLOW. Greg Cheers, Chris - Original Message - From: "Michael" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 24, 2000 5:10 PM Subject: Re: performance limitations of linux raid I find those numbers rather hard to believe. I've not yet heard of a disk (IDE or SCSI) that can reliably dump 22mb/sec which is what your 2 drive setup implies. Something isn't right. Sure it is. go to the ibm site and look at the specs on all the new high capacity drives. Without regard to the RPM, they are all spec'd to rip data off the drive at around 27mb/sec continuous. [EMAIL PROTECTED]
RE: celeron vs k6-2
-Original Message- From: Seth Vidal [mailto:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 2:39 PM To: [EMAIL PROTECTED] Subject: celeron vs k6-2 Hi folks, I did some tests comparing a k6-2 500 vs a celeron 400 - on a raid5 system - found some interesting results Raid5 write performance of the celeron is almost 50% better than the k6-2. Is this b/c of mmx (as james manning suggested) or b/c of the FPU? NOT because of MMX, as the K6-2 has MMX instructions. It could be because of the parity calculations, but you'd need to do a test on a single disk to make sure that it doesn't have anything to do with the CPU/memory chipset or disk controller. Can you try with a single drive to determine where things should be? Greg
RE: celeron vs k6-2
NOT because of MMX, as the K6-2 has MMX instructions. It could be because of the parity calculations, but you'd need to do a test on a single disk to make sure that it doesn't have anything to do with the CPU/memory chipset or disk controller. Can you try with a single drive to determine where things should be? I can probably do that test tomorrow. -sv
Re: fsck'ing RAID's
On Mon, 24 Apr 2000, Cal Thixton - President - ThoughtPort Authority of Chicago wrote:
What is the advice on whether to enable auto-fsck'ing in fstab on RAID5's?
You should, of course, since you don't want to mount a non-checked filesystem.
Seems redundant to have both fsck and raidsync run both at the same time
Well, the resync will progress really slow until fsck completes (resync uses
idle I/O bandwith)
and fsck seems to always find something amiss before resync'ing is completed.
If fsck behaviour changes depending on whether the resync is completed or not,
then you really have a serious problem at your hands.
Resync shouldn't change what is read from the array, as it only rebuilds the
parity -- the redunant information -- and doesn't affect the ``real'' 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}...:
Re: performance limitations of linux raid
There's "specs" and then there's real life. I have never seen a hard drive that could do this. I've got brand new IBM 7200rpm ATA66 drives and I can't seem to get them to do much better than 6-7mb/sec with either Win98, Win2000, or Linux. That's with Abit BH6, an Asus P3C2000, and Supermicro PIIIDME boards. And yes, I'm using an 80 conductor cable. I'm using Wintune on the windows platforms and bonnie on Linux to do benchmarks. turn udma modes on in the bios and run hdparm -d 1 /dev/hda (where hda == drive device) just FYI, 3 disk raid 5 on udma33 asus mother board + 1 udma33 promise controller. disks are maxtor 87000D8's speced at a maximum of media to interface transfer rate of 14.7 mbs -- doesn't include any seek time. my box has 128megs so ran a 500 meg bonnie. results block write = 7.9mbs block read = 10.5 mps pretty good for an old 166 K6 Michael [EMAIL PROTECTED]
Re: performance limitations of linux raid
For what its worth, we recently built an 8 ide drive 280GB raid5 system. Benchmarking with HDBENCH we got 35.7MB/sec read and 29.87MB/sec write. With DBENCH and 1 client we got 44.5 MB/sec with 3 clients it dropped down to about 43MB/sec. The system is a 600Mhz P-3 on a ASUS P3C2000 with 256MB of ram, the raid drives are 40GB Maxtor DMA66, 7200 RPM, and each is run as master on its own channel. Turning on DMA seems to be the key. Benchmarking the individual drives with HDBENCH we got numbers like 2.57MB/sec read and 3.27MB/sec write with DMA off and it jumped up to 24.7MB/sec read and 24.2MB/sec write with it on. That, and enough processing power to see that paritity calc is not a bottleneck. -- Clay J. Claiborne, Jr., President Cosmos Engineering Company 1550 South Dunsmuir Ave. Los Angeles, CA 90019 (323) 930-2540 (323) 930-1393 Fax http:www.CosmosEng.com Email: [EMAIL PROTECTED]
RE: performance limitations of linux raid
-Original Message- From: Scott M. Ransom [mailto:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 6:13 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Gregory Leblanc; bug1 Subject: RE: performance limitations of linux raid Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There's "specs" and then there's real life. I have never seen a hard drive that could do this. I've got brand new IBM 7200rpm ATA66 drives and I can't seem to get them to do much better than 6-7mb/sec with either Win98, Win2000, or Linux. That's with Abit BH6, an Asus P3C2000, and Supermicro PIIIDME boards. And yes, I'm using an 80 conductor cable. I'm using Wintune on the windows platforms and bonnie on Linux to do benchmarks. I don't believe the specs either, because they are for the "ideal" case. Believe it. I was getting about 45MB/s writes and 14 MB/s reads using RAID0 with the 2.3.99pre kernels on a Dual PII 450 with two 30G DiamondMax (7200rpm Maxtor) ATA-66 drives connected to a Promise Ultra66 controller. Then I moved back to kernel 2.2.15-pre18 with the RAID and IDE patches and here are my results: RAID0 on Promise Card 2.2.15-pre18 (1200MB test) -- ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 6833 99.2 42532 44.4 18397 42.2 7227 98.3 47754 33.0 182.8 1.5 ** When doing _actual_ work (I/O bound reads on huge data sets), I often see sustained read performance as high as 50MB/s. Tests on the individual drives show 28+ MB/s. Sounds dang good, but I don't have any of those yet... When I can get a 1350 MHz proc, I'll grab a new machine an correlate these results for myself. :-) The performance is simply amazing -- even during real work (at least mine -- YMMV). And best of all, the whole set-up (Promise card + 2X Maxtor drives only cost me $550) I simply can't see how SCSI can compete with that. Easy, SCSI still competes. It's called redundancy and scalability. It's hard to get more than 4 (maybe 8 with a big system) IDE drives attached to one box. That same thing is trivial with SCSI, and you can even go with far more than that. Here's on example. At the office, I've got a single machine with 4 internal, hot-swap drives, and two external 5 disk chassis that are both full, as well as a tape drive, a CD-ROM, and a CD-RW. The tape is about 3 feet away, and the drive chassis are more like 12, everything is well withing spec for the SCSI on this machine. With IDE, I couldn't get that much space if I tried, and I wouldn't be likely to have the kind of online redundancy that I have with this machine. I'll admit that this is the biggest machine that we have, but we're only taking care of 250 people, with about a dozen people outside of the Information Services deparment who actually utilize the computing resources. Any remotely larger shop, or one with competent employees, could easily need server that scale well beyond this machine. I don't think that SCSI has a really good place on desktops, and it's use is limited when GOOD IDE is available for a workstation, but servers still have a demand for SCSI. Greg P.S. My employer probably wouldn't take kindly to those words, so I'm obviousally not representing them here.
Re: performance limitations of linux raid
I don't believe the specs either, because they are for the "ideal" case. However, I think that either your benchmark is flawed, or you've got a crappy controller. I have a (I think) 5400 RPM 4.5GB IBM SCA SCSI drive in a machine at home, and I can easily read at 7MB/sec from it under Solaris. Linux is slower, but that's because of the drivers for the SCSI controller. I haven't done any benchmarks on my IDE drives because I already know that they're SLOW. Greg Whatever you think of the interface (ide vs scsi) you have to accept that a drives speed is dependent on its rotation speed. A 7200RPM IDE drive is faster than a 5400RPM SCSI drive and a 1RPM SCSI drive is faster than a 7200RPM drive. If you have two 7200RPM drives, one scsi and one ide, each on there own channel, then they should be about the same speed. Multiple drives per channel give SCSI an edge purely because thats what the scsi bus was designed for. You pay a big dollars for this advantage though. Glenn McGrath
RE: celeron vs k6-2
At 02:45 PM 24/04/00 -0700, Gregory Leblanc wrote: -Original Message- From: Seth Vidal [mailto:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 2:39 PM To: [EMAIL PROTECTED] Subject: celeron vs k6-2 Hi folks, I did some tests comparing a k6-2 500 vs a celeron 400 - on a raid5 system - found some interesting results Raid5 write performance of the celeron is almost 50% better than the k6-2. Is this b/c of mmx (as james manning suggested) or b/c of the FPU? NOT because of MMX, as the K6-2 has MMX instructions. It could be because of the parity calculations, but you'd need to do a test on a single disk to make sure that it doesn't have anything to do with the CPU/memory chipset or disk controller. Can you try with a single drive to determine where things should be? This may indeed be because of the MMX instructions in the K6-2. The MMX instructions in the K6-2 are SLOWER than the Intel counterparts. The FPU is also slower. If you were able to use proper 3DNow! instructions instead of MMX, you would notice a marked improvement in the K6-2's speed. The K6-III improved this somewhat, but the performance of MMX instructions didn't equal that of 3DNow! until the Athlon came along. You'll see this sort of difference if you run something like rc5 key cracking on your machine, as it has modes for using MMX or 3DNow! for its calculations. -- -=[ Stuart Young (Aka Cefiar) ]=--- | http://amarok.glasswings.com.au/ | [EMAIL PROTECTED] | ---
Re: performance limitations of linux raid
Clay Claiborne wrote: For what its worth, we recently built an 8 ide drive 280GB raid5 system. Benchmarking with HDBENCH we got 35.7MB/sec read and 29.87MB/sec write. With DBENCH and 1 client we got 44.5 MB/sec with 3 clients it dropped down to about 43MB/sec. The system is a 600Mhz P-3 on a ASUS P3C2000 with 256MB of ram, the raid drives are 40GB Maxtor DMA66, 7200 RPM, and each is run as master on its own channel. Turning on DMA seems to be the key. Benchmarking the individual drives with HDBENCH we got numbers like 2.57MB/sec read and 3.27MB/sec write with DMA off and it jumped up to 24.7MB/sec read and 24.2MB/sec write with it on. That, and enough processing power to see that paritity calc is not a bottleneck. Can you use your raid system with DMA turned on or do you get irq timouts like me ?
Re: performance limitations of linux raid
A 7200RPM IDE drive is faster than a 5400RPM SCSI drive and a 1RPM SCSI drive is faster than a 7200RPM drive. If you have two 7200RPM drives, one scsi and one ide, each on there own channel, then they should be about the same speed. Not entirely true - the DMA capabilities of IDE could provide faster transfer modes than your avg scsi card could generate. I have a 7200 RPM LVD scsi drive and a 7200RPM UDMA ide drive and the IDE wins EVERY SINGLE TIME. -sv
Re: performance limitations of linux raid
Seth Vidal wrote: A 7200RPM IDE drive is faster than a 5400RPM SCSI drive and a 1RPM SCSI drive is faster than a 7200RPM drive. If you have two 7200RPM drives, one scsi and one ide, each on there own channel, then they should be about the same speed. Not entirely true - the DMA capabilities of IDE could provide faster transfer modes than your avg scsi card could generate. I have a 7200 RPM LVD scsi drive and a 7200RPM UDMA ide drive and the IDE wins EVERY SINGLE TIME. -sv I think everyone seems to be missing the _point_ of SCSI. SCSI is NOT just about raw speed, even though some SCSI has a speed of 160MB/second. SCSI has many advantages over IDE, oe EIDE, such as command queing. Let's see your IDE drive handle 10 or 15 *simultaneous* reads/writes. let's see it have a MTBF of over 1 Million hours. Let's see it connected along with 13 other drives on the same chain. Let's see it run on cables running for several yards or meters. Let's see it conected to multiple computers. Heck, just for fun, let's run IP over IDE. Oh, wait, that's SCSI that can do that ;) The point is, comparing speed of SCSI vs any IDE variant is like comparing apples and oranges. That said, copmparing two drives of any variant, and basing their performance upon the rotational speed is also an error. RPMs are not the sole determining factor. Other factors include the size of the drive in MB/GB, and the seek or access time. I have, for example, a 5400RPM SCSI2 drive that still outperforms 7200RPM IDE drives colleagues have. I have seen 6X SCSI CDROMs that perform better than 8X EIDEs. I have a 7200RPM SCSI outperforming 10Krpm IDE drives. The determining factor in the choice of SCSI vs. IDE should be in what the machine will be doing. If all you need is a desktop machine fo rgaming and/or basic sufing/office type work, you probably don't need SCSI. if you are going to run a server that may be running some intensive I/O, and need reliability and longevity, you should be looking at SCSI, not IDE. After all, is speed is your sole criteria, chances are you are missing something. ;^) -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
Re: performance limitations of linux raid
bug1 wrote: I don't believe the specs either, because they are for the "ideal" case. However, I think that either your benchmark is flawed, or you've got a crappy controller. I have a (I think) 5400 RPM 4.5GB IBM SCA SCSI drive in a machine at home, and I can easily read at 7MB/sec from it under Solaris. Linux is slower, but that's because of the drivers for the SCSI controller. I haven't done any benchmarks on my IDE drives because I already know that they're SLOW. Greg Whatever you think of the interface (ide vs scsi) you have to accept that a drives speed is dependent on its rotation speed. Not entirely true. RPMs is but _one_ factor, not the determining factor. A 7200RPM IDE drive is faster than a 5400RPM SCSI drive and a 1RPM SCSI drive is faster than a 7200RPM drive. Not always true, if you are talking about data throughput and access speed. If you have two 7200RPM drives, one scsi and one ide, each on there own channel, then they should be about the same speed. Multiple drives per channel give SCSI an edge purely because thats what the scsi bus was designed for. You pay a big dollars for this advantage though. As well as various _other_ advantages, see otehr post. -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
