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?
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. 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
RE: Raid5 with two failed disks?
Hi all, 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? Thanks in advance, --Rainer
Copying partition information
Hi all, Is there an easy way to copy the partition information from one disk to another disk that is exactly the same size? I'm guessing a dd on the right device might do this but the exact command would be appreciated. My goal is to not have to manually fdisk multiple disks before syncing them into an existing RAID-1 array. --Rainer
Re: Promise ATA66
It does Raid 0 and 1 as well as appending. Note: http://www7.tomshardware.com/storage/00q1/000329/index.html ... for Tom's review of the card (and how to make a RAID card from the non-RAID card). Agus Budy Wuysang wrote: > Ed Schernau wrote: > > > > No, it seems that it DOES do hw RAID, but with no > > battery backup, onboard RAM, etc. > > It has no onboard RAM so why would it need battery backup? :) > > BTW, does it do striping (r5/r0) or only mirroring (r1) ? -- _/~-=##=-~\_ -=+0+=-< Michael T. Babcock >-=+0+=- ~\_-=##=-_/~ http://www.linuxsupportline.com/~pgp/ ICQ: 4835018
Re: suggested changes to raid tools
This of course suggests that the raidtab file is almost redundant itself and could be replaced by command-line options to mkraid. mke2fs certainly doesn't require an fstab entry for a filesystem before it can be created or dealt with. raidtab should be a place to keep information in case the persistant superblock is somehow damaged, imho. For example: mkraid --level=5 --device=/dev/md0 --add=/dev/sda5 --add=/dev/sdb5 --add=/dev/sdc5 --addspare=/dev/sdd5 Creating /dev/md0 with: /dev/sda5 - disk 0 /dev/sdb5 - disk 1 /dev/sdc5 - disk 2 /dev/sdd5 - spare 0 .Finished. Michael Robinton wrote: > 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. -- _/~-=##=-~\_ -=+0+=-< Michael T. Babcock >-=+0+=- ~\_-=##=-_/~ http://www.linuxsupportline.com/~pgp/ ICQ: 4835018
Re: Mylex ExtremeRAID 1100
On Sat, 1 Apr 2000, Chris Mauritz wrote: >Just thought you guys would find it amusing that this card >worked just fine with vanilla Redhat 6.1, but gives blue >screens with both NT4 and Win2K Server. Mylex swears it is >a hardware issue and is the result of bugs in the Intel Carmel >840 chipset. I find that difficult to believe as the controller >works just fine (exact same hardware) with Linux. This doesn't surprise me at all. Linux generally leaves the chipset setup just like the BIOS put it. Windows doesn't do that at all. And there _are_ lots of known (and I'm sure several unknown) bugs in the i8x0 chipsets. If it were the Mylex drivers, then it would crash other machines with different chipsets -- which it doesn't. I'm sure Mylex has had more than a few people report this as a problem so they should have an idea what's causing it. --Ricky
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: Raid5 with two failed disks?
On Sun, 02 Apr 2000, Marc Haber wrote:
[snip]
> Yes, I did. However, I'd add a sentence mentioning that in this case
> mkraid probably won't be destructive to the HOWTO. After the mkraid
> warning, I aborted the procedure and started asking. I think this
> should be avoided in the future.
I have added this to my FIX file for the next revision of the HOWTO.
Thanks,
--
: [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: Raid5 with two failed disks?
On Sun, 2 Apr 2000 15:28:28 +0200, you wrote: >On Sun, 02 Apr 2000, Marc Haber wrote: >> On Sat, 1 Apr 2000 12:44:49 +0200, you wrote: >> >It _is_ in the docs. >> >> Which docs do you refer to? I must have missed this. > >Section 6.1 in http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/ > >Didn't you actually mention it yourself ? :) Yes, I did. However, I'd add a sentence mentioning that in this case mkraid probably won't be destructive to the HOWTO. After the mkraid warning, I aborted the procedure and started asking. I think this should be avoided in the future. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: RAID Devices and FS labels
On Apr 1, 10:40pm, Theo Van Dinter wrote: } Subject: RAID Devices and FS labels > On my home machine today, I decided to change how the filesystems are listed > in /etc/fstab from the standard /dev/name to FS labels: > > LABEL=ROOT/ ext2defaults1 1 > LABEL=USR /usrext2defaults1 2 ... [ deleted ] ... > Does anyone know how the tools would handle this situation? I'd assume that > given a list of devices and labels, the RAID devices would come up first, and > then the individual partitions, but I'm not sure how this works WRT mount, > fsck, etc. > > Any ideas? Thanks. As you have already anticipated there are problems associated with using volume and filesystem label based mounting with RAID1 mirrors. I can attest from personal experience that you will end up mounting the underlying physical mirrors rather than the virtual block device. I had initiated a thread about this a couple of months ago when I ran into problems trying to get this to work. The issue got batted around a little and the general consensus was that this is indeed a problem. There were essentially no good solutions proposed at that time other than the notion of some heuristics. The overall consensus was that the /proc/partitions pseudo-file has to either present the /dev/md* devices first or mount has to explicitly look for labels on them before considering the actual physical block devices. Hopefully this information is helpful. Greg }-- End of excerpt from Theo Van Dinter As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, Inc. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-4950WWW: http://www.enjellic.com FAX: 701-281-3949 EMAIL: [EMAIL PROTECTED] -- "I'd rather see my sister in a whorehouse than my brother using windows." -- Sam Creasey
Ultra160 on Ultra2 controller
hi, all, please correct me if I am wrong. can Ultra160 HD run on Ultra2 Controller with Ultra2 speed?! I tried to put Ultra160 HD (Seagate 9G HD) on a Ultra2 controller (Adaptec 3896N), the SCSI BIOS detect the drive without errors. when I tried to install RedHat 6.1 (2.2.12) or Mandrake 7.0 (2.214), installation process just lock at detect AIC7896 SCSI. and keep having reset the SCSI bus messages under console. if I change to Ultra2 HD, the installation went through. thank you for time. Louis Fung
Re: Swapping onto RAID: Debian Style?
pardon me? On Sun, Apr 02, 2000 at 02:03:36AM +0200, Thomas Rottler wrote: > Hi! > > I have an autodetecting RAID1 swap set. The kernel does so all the work for > me... > > Thomas > -- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l.
Re: Raid5 with two failed disks?
On Sun, 02 Apr 2000, Marc Haber wrote:
> On Sat, 1 Apr 2000 12:44:49 +0200, you wrote:
> >It _is_ in the docs.
>
> Which docs do you refer to? I must have missed this.
Section 6.1 in http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
Didn't you actually mention it yourself ? :)
(don't remember - someone mentioned it at least...)
--
: [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: Raid5 with two failed disks?
On Sat, 1 Apr 2000 12:44:49 +0200, you wrote: >It _is_ in the docs. Which docs do you refer to? I must have missed this. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Ideas for swapping on RAID (was: multiple partitions)
On Sat, 1 Apr 2000, Mike Bilow 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. > > Jakob: > > If this is true, it should be added to the HOWTO. I have some ideas for how to deal with swapping on RAID. 1. Modify or wrap the invocation of the swapon program so that it takes responsibility for waiting until resyncing of its target swap volume is completed. This could be done by adding code to the swapon program itself which checked to make sure that it was not enabling swapping onto a RAID volume being resynced. While this is the more reboust approach, it would also involve modifying a fairly well established and solid program. Using a shell test against /proc/mdstat is probably more prudent. Ideally, the kernel should be able to act intelligently when swapping is enabled onto a RAID device which is being resynced and defer actual use until it is safe, so it makes more sense to fix this in the kernel than in the swapon binary -- which is really just a call to the swapon() system service anyway. 2. We should probably get some code added to the resync procedure which allows controlling the order in which resync is done so that swap partitions can be specified first. This would logically be handled as kernel arguments, something like "raidsync=md1,md0,md2" or maybe a general algorithm such as "raidsync=smallest-first". I am also not sure that it is sensible to have the kernel code default to resyncing in device order (md0, md1, ...) rather than doing smallest volumes first. Of course, if the kernel has been notified via swapon which volumes are to be used for swapping, then it is easy for it to resync these first. 3. Some way of testing for resync in progress should be added to /proc so that startup scripts are not dependent upon external tools such as grep. for example, we could have /proc/md which had a subdirectory for each device, say /proc/md/0, /proc/md/1, and so on. Each device subdirectory could have standard names such as "size," "resync," "type," and so on. This way, it would be possible to do tests such as this: if [ `cat /proc/md/0/resync` = 0 ]; then swapon /dev/md0 fi This sort of facility is going to be needed if the kernel is going to protect against enabling swapping onto RAID undergoing resync. -- Mike
