Re: raid5 failure
Hey Seth, Sorry to hear about your drive failures. To me, this is something that most people ignore about RAID5: Lose more than one drive and everything is toast. Good reason to have a drive setup as a hot spare, not to mention an extra drive laying on the shelf. And hold your breathe while the array is rebuilding. it actually will probably be ok in the long run. we had GOOD backups. it took us less than 6hours to bring the whole thing backup (including rebuilding the machine, restoring from tape and eating dinner) so I feel good about our ability to recover from a disaster. and I'm not afraid of the WORST anymore with raid5. the logs screamed holy hell so I knew what was RIGHT away. so all in all I'm glad we're through it. though a hot spare is in the plans for the next iteration of this array :) -sv
raid5 failure
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: Failure autodetecting raid0 partitions
So if Linus gets hit by a bus (or a fast moving hari krishna), how are folks to get things into the kernel then? Probably Alan. -sv
Re: speed and scaling
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+ Is this vastly read-only or will write speed also be a factor? mostly read-only. -sv
Re: speed and scaling
If you can afford it and this is for real work, you may want to consider something like a Network Appliance Filer. It will be a lot more robust and quite a bit faster than rolling your own array. The downside is they are quite expensive. I believe the folks at Raidzone make a "poor man's" canned array that can stuff almost a terabyte in one box and uses cheaper IDE disks. I priced the netapps - they are ridiculously expensive. They estimated 1tb at about $60-100K - thats the size of our budget and we have other things to get. What I was thinking was a good machine with a 64bit pci bus and/or multiple buses. And A LOT of external enclosures. If you can't afford either of these solutions, 73gig Seagate Cheetahs are becoming affordable. Packing one of those rackmount 8 bay enclosures with these gets you over 500gb of storage if you just want to stripe them together. That would likely be VERY fast for reads/writes. The risk is that you'd lose everything if one of the disks crashed. this isn't much of a concern. The plan so far was this (and this plan is dependent on what advice I get from here) Raid0 for the read-only data (as its all on tape anyway) Raid5 or Raid1 for the writable data on a second scsi controller. Does this sound reasonable? I've had some uncomfortable experiences with hw raid controllers - ie: VERY poor performance and exbortitant prices. My SW raid experiences under linux have been very good - excellent performance and easy setup and maintenance. (well virtually no maintenance :) -sv
RE: speed and scaling
i have not used adaptec 160 cards, but i have found most everything else they make to be very finicky about cabling and termination, and have had hard drives give trouble on adaptec that worked fine on other cards. my money stays with a lsi/symbios/ncr based card. tekram is a good vendor, and symbios themselves have a nice 64 bit wide, dual channel pci scsi card. can you tell me the model number on that card? which does lead to the point about pci. even _IF_ you could get the entire pci bus to do your disk transfers, you will find that you would still need more bandwidth for stuff like using your nics. right. so, i suggest you investigate a motherboard with either 66mhz pci or 64 bit pci, or both. perhaps alpha? the money I would spend on an alpha precludes that option But some of dell's server systems support 64bit buses. thanks -sv
Re: speed and scaling
FWIW, you are going to have trouble pushing anywhere near 90MB/s out of a gigabit ethernet card, at least under 2.2. I don't have any experience w/ 2.4 yet. I hadn't planned on implementing this under 2.2 - I realize the constraints on the network performance. I've heard good things about 2.4's ability to scale to those levels though. thanks for the advice. -sv
Re: speed and scaling
There are some (pre) test versions by Linux and Alan Cox out awaiting feedback from testers, but nothing solid or consistent yet. Be careful when using these for serious work. Newer != Better This isn't being planned for the next few weeks - its 2-6month planning that I'm doing. So I'm estimating that 2.4 should be out w/i 6months. I think thats a reasonable guess. -sv
RE: speed and scaling
I'd try an alpha machine, with 66MHz-64bit PCI bus, and interleaved memory access, to improve memory bandwidth. It costs around $1 with 512MB of RAM, see SWT (or STW) or Microway. This cost is small compared to the disks. The alpha comes with other headaches I'd rather not involve myself with - in addition the costs of the disks is trivial - 7 75gig scsi's @$1k each is only $7k - and the machine housing the machines also needs to be one which will do some of the processing - and all of their code is X86 - so I'm hesistant to suggest alphas for this. Another advantage of the alpha is that you have more PCI slots. I'd put 3 disks on each card, and use about 4 of them per machine. This should be enough to get you 500GB. More how - the current boards I'm working with have 6-7 pci slots - no ISA's at all. The alphas we have here have the same number of slots. Might I also suggest a good UPS system? :-) Ah, and a journaling FS... the ups is a must -the journaling filesystem is at issue too - In an ideal world there will be a Journaling File system that works correctly with sw raid :) -sv
Re: celeron vs k6-2
Raid5 write performance of the celeron is almost 50% better than the k6-2. Can you report the xor calibration results when booting them? sure I should be able to pull that out of somewhere from the k6-2: raid5: MMX detected, trying high-speed MMX checksum routines pII_mmx : 1121.664 MB/sec p5_mmx: 1059.561 MB/sec 8regs : 718.185 MB/sec 32regs: 501.777 MB/sec using fastest function: pII_mmx (1121.664 MB/sec) If possible, let the resync's finish before testing... this can cause a huge amount of variance (that I've seen in my testing). speed-limit down to 0 doesn't appear to help, either (although the additional seeks to get back to the "data" area from the currently resyncing stripes could be the base cause) I did both tests just about identically. When looking from a certain realistic POV, it'd be hard to believe that even a P5 couldn't keep up with the necessary XOR operations... is there anything else on the system(s) fighting for CPU time? no. they were blanked - i didn't put them into runlevel 1 but I did shut down everything I could. they were pretty low load. -sv
Re: celeron vs k6-2
early stepping K6-2s did not have an MTRR. later steppings do (i believe stepping 8 was the first one to have an MTRR... but i can't say for certain): my cpu: processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 0 cpu MHz : 300.689223 fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mmx 3dnow bogomips: 599.65 important flags from my cpu: flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow interesting. mtrr is there so maybe its motherboard quality. -sv
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: 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: 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: SCSI - IDE RAID Adapters
the SCSI bus on one side and emulate one disk, and on the other do hardware raid5 across 4 - 8 UDMA buses? I ask because, while not normally somthing I would do, I need to rig a large storage array in an evil environ. No way am I mounting eight 1K$ each drives in a mobile application, but 5 28G UDMA drives are 1K total, and who cares id you kill a few per year. Any leads, preferred units, etc? www.zero-d.com they have those units. -sv
Re: ext2resize
What's more, it does ... While there is evidence of this on normal drives and hw raid drives too. (I assume the `While' is spurious). I have first hand evidence of the first. I'd like to know if it will work on sw raid drives. It's independent of the underlying hardware -- ext2 just sees a set of disk blocks -- it does not care what type they are! (actually, it's best to use it on top of LVM) anyone know? I have used it on SW RAID. Just felt like I should ask first - it makes me uneasy expanding the drive - how would you go about doing this with sw raid - like how would I do it if I wanted to add a drive to the array? this might be useful to add to the howto. -sv
Re: ext2resize
What you *REALLY* want is LVM url please? pointers of some type? -sv
Re: Changing controllers strategy?
I've got a four disk RAID5 setup on one controller. I want to add another controller, but am unsure of what strategy I should adopt to maintain the RAID integrity. As the order that the disks are found and identified as sda, sdb etc. determines the RAID structure and depends on the disk ID's, how do I maintain this when I put two of them on a different controller with different ID's. I'm a bit cautious here as I've had a bad experience when experimenting with disk changing and ended up with a corrupted array. It would be nice if Jacob's great HOWTO included this sort of info and also how to recover a snarled up array. I'd do this: take the highest scsi id numbers of your drives and put them (unchanged) on the new controller which should be SECOND in the module load and pci load sequence. the linux will look at the drives like this: scsi_hostadapter0 /dev/sda /dev/sdb scsi_hostadapter1 /dev/sdc /dev/sdd If I'm wrong here someone please correct me. thanks -sv
Re: not finding extra partitions
removed the cable from one drive and rebooted for a test. All seemed to go well, system ran in degraded mode. When I reconnected drive, only 1 of the 3 partitions on the drive are recognized. 2 of my 3 /dev/md- arrays still run in degraded mode. How can I force a "good" partition so the array will rebuild? raidhotadd /dev/mdX /dev/sd?? then it reconstructs. -sv
Re: not finding extra partitions
I dug through the linux-raid archives last night and found the answer too. Got everything resynced last night. I am using RH 6.1 2.2.12-20 with a Promise EIDE-MaxII with 3 Maxtor 51536U3 ide drives; 2 of these drives on Promise card, and 3rd on secondary of motherboard. All seems to be working well. Total cost: 150*3 + 26 = 476 dollars for 30Gig of RAID5. /dev/md0 - /dev/hdc1 /dev/hde1 /dev/hdg1 mounted as /usr /dev/md1 - /dev/hdc5 /dev/hde5 /dev/hdg5 mounted as /home /dev/md2 - /dev/hdc6 /dev/hde6 /dev/hdg6 mounted as /usr1 I have a SOHO and am using the RAID5 as a "network appliance". /usr1/xtools exported as nfs and SAMBA - contains Solaris and win32 cross development tools. /usr1/rtosdev exported as nfs and SAMBA - contains development code /home exported as nfs and SAMBA - misc and NIS home directory Has anyone seen any problems in long term use of linux RAID5 in this or any other environment? if you continue to use 2.2.12-20 and are planning to do nfs you are going to run into problems - go to nfs.sourceforge.net for more information. -sv
Re: product testimonials
Notice that it checks every 3 seconds, but emails every 10 minutes (prevents the inbox from filling up overnight). What does it look like when a drive dies? I presume something like: [..UD] Then, perhaps just doing a (Perl) regexp: if (/\[[^\]]*D[^\]]*\]/) then report the failure? what I've seen is that it looks like this: [UU_UU] until the drive is marked as dead. and then it changes to: [UUDUU] (I believe) I'd want to know about the _ until otherwise noted. and I'd want to be able to touch and ignore file so if its rebuilding I don't hear about it every few minutes. I'll see what I can hack up. it wouldn't be a bad idea to put a few of these up on a raid-related website so people could see their options. -sv
failed disks
Hi, I'm doing a series of bonnie tests along with a fair amount of file md5summing to determine speed and reliability of a raid5 configuration. I have 5 drives on a TekRam 390U2W adapter. 3 of the drives are the same seagate barracuda 9.1 gig drive. The other two are the 18 gig barracuda's. Two of the nine gigs fail - consistently - when I run bonnie tests on them. One will get flagged as bad in one run and die out. This one I can confirm is bad b/c it fails on its own outside of the raid array (it fails to be detected by linux at all - no partitions are found and it can't be started) - the other passes a badblocks -w test and appears to work. However it ALWAYS fails when its a part of the array and a bonnie test is run. Does this sound like a hardware fault? If so why is it only occurring when raid is used? thanks -sv
Re: product testimonials
Well, we've been using assorted versions of the 0.90 raid code for over a year in a couple of servers. We've had mostly good success with both the raid1 and raid5 code. I don't have any raid5 disk failure stories (yet ;-), but we are using EIDE drives so I expect one before TOO long ;-) Raid5 has given us good performance and reliability so far. Now, we do have a raid1 array that did something interesting (and bad). One of the drives was failing intermittently (and fairly silently) and had been removed from the array. Unfortunately, backups were also failing (again, fairly silently). On a normal power down / reboot, it appears that the wrong drive was marked as master and on the reboot it re-synced to the drive that had been out of the array for a couple of months. (yeah, yeah, we need a sys-admin ;-) Anyway, 2 months of data went down the tubes. No level of raid is a replacement for good backups. On the subject of semi-silent failures: Has anyone written a script to monitor the [U]'s in the /proc/mdstat location? It would be fairly trivial (start beeping the system speaker loudly and emailing repetitively) Has this already been or should I work on it? Thanks -sv
product testimonials
Hi folks, I've got a user in my dept who is thinking about using software raid5 (after I explained the advantages to them) - but they want "testimonials" ie: - people who have used software raid5 under linux and have had it save their ass or have had it work correctly and keep them from a costly backup restore. IE: success stories. Also I would like to hear some failure stories too - sort of horror stories - now the obscure situations I don't care about - if you got an axe stuck in your drive by accident and it killed the entire array then I feel sorry for you but I don't consider that average use. Can anyone give some testimonials on the 0.90 raid? thanks -sv
Re: mkraid secret flag
How about --force / -f look for $HOME/.md_force_warning_read and if not exists: - print huge warning (and beep thousands of times as desired) - creat()/close() the file how about an expiration on the timestamp on this file ie: if the time is longer than 2 weeks make them read it again. I know I forget all sorts of warnings after a while :) -sv
Re: raid5 on 2.2.14
If the partition types are set to "fd" and you selected the "autorun" config option in block devices (it should be turned on on a rawhide-type kernel), raidstart shouldn't be necessary. (the kernel will have already started the md arrays itself, and the later initscripts raidstart call won't be necessary). Could you paste any "autorun" section of md initialization during boot? does the same problem appear even if you build-in raid5? (first-pass debugging of building-in all raid-related scsi and md modules just to get initrd and module ordering issues out of the way might help) after you boot, does /proc/mdstat show the array? active? if you boot into single-user mode, is the array already active? what's the raidtab contents? Note that as coded, the initscripts should only be attempting to raidstart inactive arrays, but I never checked to make sure that the code actually worked as intended. Given that, I don't really think any of the above really helps, but it's something to throw out there :) I think I figured it out. the drives came off of an older sun. They still had the sun disklabels on them. I never remade the new disk labels before repartitioning. I think when I rebooted the disklabels got in the way of the disks being recognized correctly and it ate the drive. I also found out later than one of the drives I was using had somesort of fairly heinous fault. It would detect but would only occasionally be found by linux. I took it out of the array I think I'm going to rma it. thanks for the help. As an additional question. What sort of numbers should I be seeing (performance wise) on a u2w 4 disk array in raid5. I'm getting about 15MB/s write and 25MB/s read but I wouldn't mind getting those numbers cranked up some. I'm using 32K chunksize with the stride setting correctly set (as per jakob's howto). I'm testing with 500MB/1000MB/1500MB/2000MB bonnie tests. The machine is a k6-2 500 with 128MB of ram Scsi controller is a tekram 390U2W The disks are seagate 7200RPM's baracudda (18 and 9 gig versions) I'm using 1 9gig partition of each of the 18 gig drives and the whole drive on the 2 9 gig drives. thanks -sv
raid5 on 2.2.14
Hi folks, got a small problem. I'm running redhat 6.1+ (2.2.14-5.0 kernels from rawhide and new raidtools 0.90-6) I've checked and the 2.2.14-5.0 are using the B1 patch from mingo's page. I think the raidtools they are using (mentioned above) are the correct version. Here is what happens: I build a raid 5 array (5 disks) it builds and I can mount and write things to it. I'm not doing root fs on it but I build a new initrd anyway - it builds and includes the raid5 modules - I rerun lilo. I boot. I get raidstart /dev/md0 invalid argument /dev/md0 I've checked the archives and it looks like others have experienced this problem but they've all been related to other issues. is there something i'm missing? I think I've covered all the bases. any ideas? thanks -sv
Re: Large files 2GB+ RAID?
Unfortunately the hardware RAID still doesn't solve the 2GB+ problem. I also have a hard time with the 'if you want big files, buy a 64 bit machine' argument. What percentage of Linux users are on 64 bit platforms? How many other x86 OS's support 64 bit filesystems (NT, FreeBSD, BeOS, Solaris, etc)? This is a serious impediment to Linux being a server OS, and is most likely going to make us switch to FreeBSD for our projects - even though I much prefer Linux (and know it better). Sure would be nicer to stay with the penguin then turn to the devil frightenlingly bad puns should be left out of this mailinglist. :) I thought there were motions to backport the BIGMEM patches to 2.2 (unofficial patch of course) any clarification would be useful. -sv
dac960 and weird problem
I have a accelraid 250 w/32mb of ram. I've setup 3 ibm 18 lzx drives (18gig 10krpm LVD drives) on it in a raid 5 configuration. Everything comes up great and functions just fine - but: If I soft reboot the system (ie:ctrl-alt-del or init 6) the dac960 will fail to detect the drives. If I hard-reboot (power off-power on) then everything is peachy. this is a mild annoyance - I'm open to suggestions. I've talked to mylex tech support and they said "change/remove the terminator to see if thats the problem - I did this. - no other suggestions are forthcoming) As well in raid-5 formation the performance on these drives (read and write) is not so hot. I ran bonnie with a -s of 1500MB and the write performance came in at about 5.5-6MB/s - not wonderful - Read was better about 18MB/s - but I thought it would be MUCH better than that. Suggestions are welcome here too. Thanks -sv
Re: Large files 2GB+ RAID?
Ah, sorry for the puns and any confusion. I am talking about 2GB+ file sizes, not memory. The also proves my point - we now have 4GB memory on 32 bit systems - which is only applicable for a VERY small percentage of Linux users, but not 2GB files on 32 bit systems (once again - even though many other 32 bit OSes have them)... Jason My understanding is that the bigmem patches are FS patches not memory patches - they are inappropriately named perhaps. maybe I'm off. -sv
Re: Large files 2GB+ RAID?
Nope. Bigmem was for 4 GB RAM and such, and has been pretty much replaced by highmem (all culled from the Linux Memory Management mailing list). All of the 2GB file stuff is refereed to mostly as Large File Summit (LFS) not to be confused with Log File System (LFS - no idea what it does. Some sort of journal type thing). Once again, any information about large files under RAID would be much appreciated. The pull of FreeBSD is almost inescapable. ahh but freebsd smp is in sore shape in comparison to linux smp. so there is that point. -sv
Re: ide hardware raid
check out www.zero-d.com They make an eide internal uw scsi external raid box that looks pretty cool. -sv
zero-D raid chassis
has anyone on this list used or had any dealing's with the Zero-D UDMA internal SCSI external Raid Arrays? this is the URL (the 400 model specifically) http://www.zero-d.com/ide2.html I'm interested for use with linux and/or solaris and I'd love to know of any feelings or responses. They look like a good deal in that replacement cost on these units is low (due to IDE drives) and I'd like to hear opinions on them. Thanks -sv
Re: ide and hot swap
While I'll be the last person to praise IDE, recent drives and controllers have CRC error checking, which is actually better than parity. would you happen to know which drives and controllers? The promise udma66's? Any WD IDE's or IBM's 36+gig. -sv
RE: ide and hot swap
Price wise, this seems like a good approach. If it were my system, I would be concerned about disaster recovery. I have been a believer for a long time in tape rotation and offsite storage. Also, you are risking losing 4 weeks worth of data; a full backup at least weekly and incremental backups can save your business. You not only should think about system failures, but fires, floods, etc. An onsite disk storage scheme doesn't take these situations into account. Perhaps, if you want to consider alternate storage, you should look at optical media or some other approach. but I'm talking about doing full rotations. Right now we're loading 7 tapes into the DLT jukebox and it rotates for a month through those. Then the level 0 tapes come out and go to my house for offsite storage. We start over (more or less) every month. I was proposing using 2 or 3 big ide's every month. We do risk losing 4 weeks from a fire but we Always have risked that. But all other storages are offsite. You risk losing whatever's in the room at the time of a fire. While 4 weeks is greater than 1 day it might be a tolerable risk. my biggest concern is MTBF and not fires. Fires are a mess but your data (while important) is not the first concern after a fire - rebuilding is. Its the random drive failures and overwrites that I think most backups protect from. -sv
ide and hot swap
I know this has been covered before but I can't find a searchable archive of this list anywhere. We've got DLT's doing backups right now and we're conceiving that it might be cheaper to setup a system with 2 or 3 linear striped or raid 0 34+gig ide disks and have 2 sets of these disks that we swap out week to week for backups - rather than spend a fortune in DLT tapes and deal with a whopping 4MB/s transfer time. We would be using a set of disks for 4 weeks then swapping out to another set - the other set would be fresh formatted at that point and would be ready to go for the next month's backups. What I'm most interested in is if anyone has seen. 1. external inclosures for ide disks and if there is any hotswap support for ide devices in the kernel. I figure 4 disks across 2 controllers while not an optimum situation would see a HUGE speed boost over DLT drives. And with IDE drive prices dropping like crazy We'd eventually be at a point where the media would almost be cheaper than DLT media. With potential expansion of ide drives into the 100's of gigabyte range this might make a worthwhile effort. any ideas/suggestions. -sv
Re: moving /lib - off topic advice wanted
Or am I going to run into trouble because /lib's files will be unavailable for a bit while I enter these commands? Is there a better way to enlarge /? In general how to you recommend changing partition sizes? Is this an argument for not seperating directories into different partitions, since it's harder to keep the free space evenly distributed? I think unless your drive mounting and init binaries are statically linked you're going to hit trouble at boot time. However have you sifted through /lib to find out if you have an libraries with debugging codes left in or binaries that have been upgraded and/or ones you can recompile to put in /usr/lib ? -sv
Re: moving /lib - off topic advice wanted
Perhaps I am wrong, I expected that a reboot would make the original /lib available again at boot time. The data is still there, just hidden by the mount, right? mounting only occurs after fstab is processed. you can't process fstab with the mount command if there are no libraries for mount to rely on. see the problem? -sv
Re: Hot Swap
I doubt it, unless the controller is hotswap capable and you can reload the IDE driver I don't know of any hotswap capable IDE controllers (Not to say that I wouldn't be interested if anyone else on the list does!!!) I would as well be interested in a hot-swappable ide controller. -sv
benchmarks
I've mostly been a lurker but recent changes in my company have peaked my interest in the performance of sw vs hw raid. Does anyone have some statistics online of sw raid (1,5) vs hw raid (1,5) on a linux system? Also is there anyway to have a hot-swappable sw raid system. (IDE or SCSI)? RTFM's and web page pointers are gladly accepted. thanks -sv
Re: benchmarks
I've mostly been a lurker but recent changes in my company have peaked my interest in the performance of sw vs hw raid. Does anyone have some statistics online of sw raid (1,5) vs hw raid (1,5) on a linux system? We have a DPT midrange SmartRAID-V and we're going to do testing on two 7 x 17.5 GB RAID 5 arrays, one software, one hardware. We'll post the results as soon as they're available. (Testing will happen on a dual PII 350 w/ 256 MB RAM a cheezy IDE disk for /, running 2.2.6 (or later).) What kind of tests would people like to see run? The main test I'm going for is simply stability under load on bigish file systems biggish file operations. stability and read performance speeds and write performance speeds. possibly optimization for mostly-read situations, mostly-write situations and then both read and write situations. -sv
Re: WD hard drive raid-1 issues
Hello all, We are planning on using RAID-1 to mirror two identical drives. The drives are set up the same in bios, CHS mode with 25228 cylinders, 16 heads, ande 63 sectors each. Linux sees them and shows the same setup as the bios. Linux fdisk on the other hand, shows different setups for the drives. One(hdb) has 1582 cylinders and 255 heads, while the other(hdc) has 25228 cylinders and 16 heads. We were wondering if this was a problem that would be preventative to implementing RAID-1 mirroring, and if so how we can set things right. I know this may be something you've already looked at but check to see if LBA mode is turned on or off in the bios. -sv
