Re: raid autodetect problem
You could probably make it work OK by using initrd and loading the module with the script, but compiling in support would be much more straightforward. On Sat, 12 Aug 2000, Christian Bucher wrote: > Hermann 'mrq1' Gausterer wrote: > > > > if you have a raid-root-fs, then > > i think the problem is that the kernel cannot load > > the modules unless the rootfilessystem is mounted > > and /lib/modules/ is available. but without > > the module, a mount is not possible. :-o > > Looks like raid-root-fs and /boot partition produces a similar situation. > > > > have you tried with compiled in support ? > > Of course it's working compiled into the kernel. > > > > ciao > > christian > > -- > +--- > | Christian Bucher > | phone: +43 1 5488640 mobil: +43 699 1 4208334 > | mailto:[EMAIL PROTECTED] > +--- >
Re: Failure autodetecting raid0 partitions
On Sat, 15 Jul 2000, Chris Mauritz wrote: > > From [EMAIL PROTECTED] Sat Jul 15 19:29:44 2000 > > > > Edward Schernau wrote: > > > > > Wow, an email CCed to Linus himself! *faint* > > > > Well do you know of another way to get a patch into the kernel ?? > > So if Linus gets hit by a bus (or a fast moving hari krishna), how > are folks to get things into the kernel then? > You send it to Alan Cox
Re: Monster machine and OpenLinux 2.3
On Sat, 24 Jun 2000, Bill Parker wrote: > I have a monster puter (Dual Pent-III 500, dual P/S (hot swap), > 256MB ram, 9GB SCSI HD, AIC 7895 controller, 4x9GB Raid ARRAY (SA-1130), > etc...I am thinking of installing linux on this beast, but would like to > know if there is native RAID support for this machine...if you need more > details, write back and I will do my best to supply info > What kind of "native" did you have in mind. Linux software raid is pretty native to linux since 2.0x I run it on my dual Celron 500, 756mb ram, dual 30gig segate 66ultras -- manages a nice 20meg xfer rate for read and write, not bad when the platter max is 26megs. I wouldn't exactly call this a monster, but the case is bigger than I like.
Re: LILO dies at LI
make sure and manually rdev your kernel On Mon, 12 Jun 2000, Ryan Mack wrote: > Running kernel 2.2.16-RAID (SMP) with LILO version 21 with attached > raidtab (summary: mirrored /boot, striped /, both split across the same > two drives). When I run lilo and reboot, lilo dies after printing LI To > get my system to boot, I have to boot off of the RedHat CD-ROM (in rescue > mode and mount my drives drives and run lilo with the redhat 2.2.14-12smp > kernel. Then everything works groovy. Any ideas what's wrong? Thanks, Ryan > >
Re: Raid-1 boot problems
> > I am currently having problems mounting my root file system that > is set up with RAID-1. The initrd image I am using conatins all the raid > tools, and successfully starts all the raid devices, but then I get the > familiar message "Kernel panic: VFS: Unable to mount root fs on 00:00". > The fstab on the initrd correctly shows /dev/md0 as /, and the > "raidstart -a" command executed by the /linuxrc produces all the > expected output. At the end, I still don't have a root filesystem. > The usual problem is that you are booting with a kernel that has not had rdev done directly on the kernel -- lilo won't do it for you when you use initrd or boot from an image file.
linux-raid@vger.rutgers.edu
> We had some problems with raid-1 & lilo to allow booting > from /dev/hda and /dev/hdc. > See Boot+Root+Raid+Lilo at the Linux Documentation Project or ftp.bizsystems.net/pub/raid/Boot+Root+Raid+LILO.html
Re: IDE Controllers
> 2.2.14 did not work for me. I have a dual PIII with onboard UDMA33 > controller running RAID1. Very stable. When I just moved the > two drives to a Promise Ultra66 the system became very unstable > (uptimes in minutes). YMMV. Hmmm I'm running 2.2.14 with latest Promise driver from their site. Raid 5 running just fine.
Re: performance limitations of linux raid
> > > > > > Not entirely, there is a fair bit more CPU overhead running an > > > IDE bus than a proper SCSI one. > > > > A "fair" bit on a 500mhz+ processor is really negligible. > > > Ehem, a fair bit on a 500Mhz CPU is ~ 30%. I have watched a > *single* UDMA66 drive (with read ahead, multiblock io, 32bit mode, and > dma transfers enabled) on a 2.2.14 + IDE + RAID patched take over 30% > of the CPU during disk activity. The same system with a 4 x 28G RAID0 > set running would be < .1% idle during large copies. An exactly > configured system with UltraWide SCSI instead of IDE sits ~ 95% idle > during the same ops. Try turning on DMA
Re: performance limitations of linux raid
On Thu, 4 May 2000, Christopher E. Brown wrote: > On Wed, 3 May 2000, Michael Robinton wrote: > > > The primary limitation is probably the rotational speed of the disks and > > how fast you can rip data off the drives. For instance, the big IBM > > drives (20 - 40 gigs) have a limitation of about 27mbs for both the 7200 > > and 10k rpm models. The Drives to come will have to make trade-offs > > between density and speed, as the technology's in the works have upper > > constraints on one or the other. So... given enough controllers (either > > scsii on disk or ide individual) the limit will be related to the > > bandwidth of the disk interface rather than the speed of the processor > > it's talking too. > > > Not entirely, there is a fair bit more CPU overhead running an > IDE bus than a proper SCSI one. A "fair" bit on a 500mhz+ processor is really negligible. >
Re: performance limitations of linux raid
The primary limitation is probably the rotational speed of the disks and how fast you can rip data off the drives. For instance, the big IBM drives (20 - 40 gigs) have a limitation of about 27mbs for both the 7200 and 10k rpm models. The Drives to come will have to make trade-offs between density and speed, as the technologys in the works have upper constraints on one or the other. So... given enough controllers (either scsii on disk or ide individual) the limit will be related to the bandwidth of the disk interface rather than the speed of the processor it's talking too. On Wed, 3 May 2000, Christopher E. Brown wrote: > On Sun, 23 Apr 2000, Chris Mauritz wrote: > > > > I wonder what the fastest speed any linux software raid has gotten, it > > > would be great if the limitation was a hardware limitation i.e. cpu, > > > (scsi/ide) interface speed, number of (scsi/ide) interfaces, drive > > > speed. It would be interesting to see how close software raid could get > > > to its hardware limitations. > > > > RAID0 seemed to scale rather linearly. I don't think there would be > > much of a problem getting over 100mbits/sec on an array of 8-10 ultra2 > > wide drives. I ultimately stopped fiddling with software RAID on my > > production boxes as I needed something that would reliably do hot > > swapping of dead drives. So I've switched to using Mylex ExtremeRAID > > 1100 cards instead (certainly not the card you want to use for low > > budget applications...heh). > > > Umm, I can get 13,000K/sec to/from ext2 from a *single* > UltraWide Cheeta (best case, *long* reads, no seeks). 100Mbit is only > 12,500K/sec. > > > A 4 drive UltraWide Cheeta array will top out an UltraWide bus > at 40MByte/sec, over 3 times the max rate of a 100Mbit ethernet. > > --- > As folks might have suspected, not much survives except roaches, > and they don't carry large enough packets fast enough... > --About the Internet and nuclear war. > >
Re: mkraid aborts without any useful info written to syslog
On Tue, 2 May 2000, Jeff Fookson wrote: > I'm having problems configuring a 2-disk RAID-1 array on an i686 > machine. The machine has Redhat 6.2 installed > > > cat /proc/mdstat > Personalities : [1 linear] [2 raid0] [3 raid1] [4 raid5] > read_ahead not set > md0 : inactive > md1 : inactive > md2 : inactive > md3 : inactive > - Old raid tools get a clean kernel from kernel.org -patch it with the latest raid patch as well as the promise patch u mentioned and you should be in good shape. See: ftp://ftp.bizsystems.net/pub/raid/ BootRootRaidLilominihowto for details. You don't have to run root raid, but a synopsis is there as well as pointers to the current 0.90 raid tools Software HOWTO. Sorry I can't post it, I'm at home and dont'have the reference.
Re: performance limitations of linux raid
On Sun, 23 Apr 2000, bug1 wrote: > Chris Mauritz wrote: > > > > > Hi, im just wondering has anyone really explored the performance > > > limitations of linux raid ? > > > > Ive just managed to setup a 4 way ide raid0 that works. > > The only way i can get it working is to use *two* drives per channel. > I have to do this as i have concluded that i cannot use both my onboard > hpt366 channels and my pci hpt366 channels together. > > Ive done some superficial performance tests using dd, 55MB/s write > 12MB/s read, interestingly i did get 42MB/s write using just a 2 way ide > raid0, and got 55MB/s write with one drive per channel on four channels > (i had no problem writing, just reading) so surprisingly i dont think > the drive interface is my bottleneck. > IDE will always beat SCSI hands down for price/performance, but scsi is > clearly the winner if you want 4 or more drives on one machine, as ide > just doesnt scale. one of the ABIT boards comes with 4 onboard IDE controllers instead of the usual 2. As I recall, the kernel software will allow you to run up to 8 ide pci channels, and the 2.4 kernel reportedly will do more. Michael
Re: Tired of Spam
> > I'm tired of being spammed, and obviously the list admins are schmucks to > > leave the list open to spammers. > > I have unsubscribed. > > There are ways to deal with spammers, other than crippling the lists > by closing them. > Closing the list will not cripple it. I maintain a list with 2200+ members that grows about 50 - 100 every month. It is hardly crippled. What it allows us to do is zap the occasional spammer instantaneously.
Re: 2.2.12 & promise does not work
Check the promise site for new drivers On Sat, 8 Apr 2000, octave klaba wrote: > Hi, > I have plus 3xpromise with 5x20Go ide to test raid5 > and I have some problems: > - only 2 carts works !? > - I run radhat6.1 and promise is not detected !? > > pff :((( > > have you any idea ? > thanks > > Octave > > -- > Amicalement, > Octave > > no swap allowed < >
Re: LILO error with a raid-1 /
On Wed, 5 Apr 2000, Sean Millichamp wrote: > After that, I modified LILO to mount the root partition off of /dev/md0, > ran lilo (it worked), and rebooted fine. Less the 48 hours later I am > trying to rerun lilo on the same machine and it won't run. The only > change I made were to delete the now useless boot targets for the old > drives/partitions (that no longer exist). This isn't critical right this > instant but I am worried I won't be able to do routine things such as, > say, upgrade my kernel without using a boot floppy (yuck). > raid will boot quite nicely from a standard lilo if the config file is properly set up. I have several raid1 and raid5 (with raid one boot partions) running that use standard lilo on both scsi and ide systems. I'm at home at the moment so I will have to post a complete answer with examples config files + explainations tomorrow. Please be patient and I will get you the info. Michael
Re: RAID-1 Non-destructive mirroring
It need not be destructive. set up raid 1 mirroring with the original disk marked as failed, create the raid and run it. cp -a old disk / to /dev/mdx / set up lilo for raid1, make a boot diskett, boot from it and mount the raid1. fix the raidtab and raidhotadd the old disk to the array. reboot and you are in business. Michael On Wed, 5 Apr 2000 [EMAIL PROTECTED] wrote: > > Is there any sign of RAID-1 that's non-destructive? This is making my > life living hell right now. :) > > I haven't been keeping up, so if there is a 2.2 patch or perhaps > something in 2.3 that supports it, I would be most gracious (perhaps a method > that isn't described in the howto?) > > I would really like to be able to walk into a good portion of my > clients and offer this, but the tedium of backup/partition/bootdisk/raid > setup/restore is too much on a time-per-hour basis to offer them... I > unfortunately have been having to offer "new technology" to long-standing > UNIX clients who demand RAID-1 (which sickens me) to cover these needs since > the price of hardware RAID controllers is even worse (and slower). > > Any help or kludges that can get me around this would be greatly > appreciated. > > -- > Erik Hollensbe > I-Net Consultants > [EMAIL PROTECTED] >
RE: Raid5 with two failed disks?
> Hmm, well, I'm certainly not positive why it wouldn't boot and I don't have > the logs in front of me, but I do remember it saying that it couldn't mount > /dev/md1 and therefore had a panic during boot. My solution was to specify > the root device as /dev/sda1 instead of the configured /dev/md1 from the > lilo prompt. Hmm the only time I've seen this message has been when using initrd with an out of sync /dev/md or when the raidtab in the initrd was bad or missing. This was without autostart. Michael > > The disk is marked to auto raid start and marked as fd. And, it booted just > fine until the "dumb" shutdown. > > As for a rescue disk I'll put one together. Thanks for the advice. > > --Rainer > > > > -Original Message- > > From: Michael Robinton [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 03, 2000 8:50 AM > > To: Rainer Mager > > Cc: Jakob Ostergaard; [EMAIL PROTECTED] > > Subject: RE: Raid5 with two failed disks? > > > > Whether or not the array is in sync should not make a difference to the > > boot process. I have both raid1 and raid 5 systems that run root raid and > > will boot quite nicely and rsync automatically after a "dumb" shutdown > > that leaves them out of sync. > > > > Do you have your kernel built for auto raid start?? and partitions marked > > "fd" ? > > > > You can reconstruct you existing array by booting with a kernel that > > supports raid and with the raid tools on the rescue system. Do it all the > > time. > > > > Michael > > >
RE: Raid5 with two failed disks?
On Mon, 3 Apr 2000, Rainer Mager wrote: > I think my situation is the same as this "two failed disks" one but I > haven't been following the thread carefully and I just want to double check. > > I have a mirrored RAID-1 setup between 2 disks with no spare disks. > Inadvertantly the machine got powered down without a proper shutdown > apparently causing the RAID to become unhappy. It would boot to the point > where it needed to mount root and then would fail saying that it couldn't > access /dev/md1 because the two RAID disks were out of sync. > Anyway, given this situation, how can I rebuild my array? Is all it takes > is doing another mkraid (given the raidtab is identical to the real setup, > etc)? If so, since I'm also booting off of raid, how do I do this for the > boot partition? I can boot up using one of the individual disks (e.g. > /dev/sda1) instead of the raid disk (/dev/md1), but if I do that will I be > able to do a mkraid on an in-use partition? If not, how do I resolve this > (boot from floppy?). > Finally, is there any way to automate this recovery process. That is, if > the machine is improperly powered down again, can I have it automatically > rebuild itself the next time it comes up? > Whether or not the array is in sync should not make a difference to the boot process. I have both raid1 and raid 5 systems that run root raid and will boot quite nicely and rsync automatically after a "dumb" shutdown that leaves them out of sync. Do you have your kernel built for auto raid start?? and partitions marked "fd" ? You can reconstruct you existing array by booting with a kernel that supports raid and with the raid tools on the rescue system. Do it all the time. Michael
suggested changes to raid tools
I'm in the process of upgrading another production system from old tools to new and noticed that you can't do a "raidstop" unless there is a valid raidtab. It seems to me that with a persistent superblock, this should not be necessary. The same applies to raidstart. Unless there is some reason to change the raid configuration -- i.e. remove or deactivate a piece, the superblock should provide all the necessary information. For raid to go mainstream, these minor things should be cleaned up. The docs seem to indicate that once the mkraid is done, the raidtab is really not needed. That is not true in the case with raidstop, raidstart, initrd starts and raid over raid (10, 51, etc...). All the info is there, the raidtab is redundant and will cause errors if not up todate or is missing. Michael
RE: multiple partitions
On Sat, 1 Apr 2000 [EMAIL PROTECTED] wrote: > On Fri, 31 Mar 2000, Michael wrote: > > > hmmm. the remirroring code is not very smart... as I recall it > > does the remirroring in order .. i.e. md0, md1, etc... This would > > imply that if you have a power fail or other crash that causes both > > md's to be faulty, the system will not be able to swap until md0, > > then md1 is remirrored. The boot and swap md's should always be the > > first two raid partitions under this scenario as they are very small > > and will remirror quickly allowing swapping to proceed while the main > > array remirrors. > > Isn't that exactly what we want to avoid? As I understand swapping on RAID > while a resync is in progress is BAD. > > But I agree this would be the way to go when this bug is fixed... > You should read the whole thread. The purpose is to delay mounting the swap partition until the resync is complete on the raid/swap device, then proceed to mount it. When the resync is ordered, 0, 1, 2, this can result in very long delays if the swap device is not 0, since that would result in the main data partition being resynced first -- which takes a long time. Resyncing the swap partition of at most a few hundred megs takes a couple of minutes or seconds if you have a bodacious processor and very fast disks. This allows normal operation and swapping to proceed while the resync of the main array takes place in the background.
Re: raid parity and mmx processor
On Sun, 19 Mar 2000, Martin Eriksson wrote: > - Original Message - > From: "Michael Robinton" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, March 19, 2000 9:54 AM > Subject: raid parity and mmx processor > > > > As I understand it, the kernel tests parity calc speed and decides to > > use/not use mmx based on which is faster. > > > > Assuming an otherwise heavily loaded cpu, would it not be better to use > > mmx even though slightly slower just to free up cpu cycles for other > tasks. > > If you are doing the calculations faster, it takes shorter time before the > CPU is free to do other things. Fastest is fastest. > Hmmm not really, if so, why would we have multi-processor systems. mmx is a distinct processor apart from the fpp or main cpu. It is possible for all to be doing separate operations at the same time. i.e. gzip, raid parity, network traffic > > > > If I don't have the right picture here, someone please provide an > > explaination of where the cpu cycles go to raid. > > > > This reason for my question is the amount of "nice" cycles on one of my > > machines that is fairly busy. Only raid5d is niced, and I'm running a > > load factor over one consistently with only about a 20% cpu load. It > > appears most of the cpu cycles in use go to raid5 -- presumably parity > > calculations. > > What kinda disks are you running on? SCSI? IDE? If IDE, do you have all nice > things such as DMA transfers enabled? > IDE 33 +dma > > > > Assuming I'm not too far off base, it would be nice to have a /proc > > option or at least a compile option to force use of mmx for raid parity > > and a way to run the parity calculation test manually to see the > difference > > between the two methods. > > Maybe not for speed, but for bug tracing. Anyway, that would be good. > > >
raid parity and mmx processor
As I understand it, the kernel tests parity calc speed and decides to use/not use mmx based on which is faster. Assuming an otherwise heavily loaded cpu, would it not be better to use mmx even though slightly slower just to free up cpu cycles for other tasks. If I don't have the right picture here, someone please provide an explaination of where the cpu cycles go to raid. This reason for my question is the amount of "nice" cycles on one of my machines that is fairly busy. Only raid5d is niced, and I'm running a load factor over one consistently with only about a 20% cpu load. It appears most of the cpu cycles in use go to raid5 -- presumably parity calculations. Assuming I'm not too far off base, it would be nice to have a /proc option or at least a compile option to force use of mmx for raid parity and a way to run the parity calculation test manually to see the difference between the two methods. Michael
Re: Could one disk cause all this, or is it a bug in Linux-RAID?
On Sun, 5 Mar 2000, Johan Ekenberg wrote: > > > About the crashes I reported yesterday: > > > I received several mails suggesting cable problems, > > > Power supply failure etc, so maybe I did not make > > > my self clear enough: I've replaced all hardware > > > except the disks. The disks have been checked > > > > How many disk controllers are involved here? If there is more than one > > drive per controller it is "possible" for a single disk that has a scsi > > bus problem to conceivably cause this -- scsi is supposed to be pretty > > bullet proof (you did say scsi, don't have original post) > > The Epox mb. has only one AIC7890 controller for U2W (LVD). All six drives > are on this controller. > > Perhaps I have to replace all disks as well then... > Hmm... scsii is pretty tough to mess up, but it is possible. Are there any error messages in any of the logs from the scsii bus? Still suspicious of a cable problem. I've had them where things at both ends work fine and the stuff in the middle throws errors.
Re: SV: Could one disk cause all this, or is it a bug in Linux-RAID?
On Sun, 5 Mar 2000, Johan Ekenberg wrote: > About the crashes I reported yesterday: > I received several mails suggesting cable problems, > Power supply failure etc, so maybe I did not make > my self clear enough: I've replaced all hardware > except the disks. The disks have been checked How many disk controllers are involved here? If there is more than one drive per controller it is "possible" for a single disk that has a scsi bus problem to conceivably cause this -- scsi is supposed to be pretty bullet proof (you did say scsi, don't have original post)
Re: question about reconstruction
> > > I plan to upgrade from old-style to new-style-raid, but on a 2.2.12 kernel. > > Go to directly to 2.2.14, and use the patch announced on the list several > times. It works correctly for me. > I recently upgraded from 2.0.33 /0.42 tools to 2.2.14 /0.90 tools autostart with no problem at all. I built a small raid first on swap partitions to proof the exact steps and when it went perfect, just did it on the production array. Worked great.
Re: RAID5 and 2.2.14
> Anyone successfully gotten raid 5 working with the new 2.2.14 kernel? > I downloaded the 2.2.14 kernel source tree and installed it, then > downloaded Mingo's 2.2.14 raid patch. The patch appeared to work fine on > the first few hunks, then failed miserably on the last 100 or so Yes, I converted an old 0.42 raid5 system last week and delivered a customer raid1 system, both with a virgin 2.2.14 kernel + mingos latest patch. No problems at all. The kernels were built on a clean 2.2.13 (non-raid) system. get your kernel from kernel.org make sure you: patch -p1
