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. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Power Supply for multiple disks?
One argument against spinning the disk down, is the on/of power cycles can kill it faster than just leaving it on... Just like a light bulb. At 12:17 PM 4/8/00, dek_ml wrote: >On Sat, 8 Apr 2000, Mike Bilow wrote: > > > Why on earth would you even bother with RAID on a machine which can > > experience 30 minutes of idle time? We only use RAID for machines which > > run web servers, mail servers, name servers, and things like this. Such > > machines here never exeperience even a solid minute of idle time. > > > > -- Mike > >Look at what "problem" RAID was designed to solve and you'll see the >answer to your question. RAID exists to provide higher performance, >higher reliability, and greater scalability than single large disks. > >I can think of a very good example of a system with 30 minutes of idle >time: a fileserver serving up a data disk which is used frequently >9-5 while the staff is in the office, but only sporadically during the >night. > >Now, the question really is "should my RAID disks spin down"? Well, >why do disks spin down? To increase longevity? To decrease power >consumption? I can't see either of those being valid arguments in a >RAID environment because 1) individual drive longevity is not important in >RAID- when a disk fails you replace it and 2) if you're doing something >important enough for RAID, you can probably afford the extra power draw >:-) === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: What the hell is this?
At 05:57 PM 4/7/00, Marc Mutz wrote: >David Cooley wrote: > > > > > > > And unfortunately, the lists aren't "closed". > > Anyone posts to "[EMAIL PROTECTED]" and it's sent to all members, > > regardless of whether the sender is subscribed or not. > > > > >And that is A Good Thing(tm). Stop it. Not a flame war about that crap >_again_! >vger policy is to allow unsubscribed users to post. Full stop. If you >don't like it, go away. > >Sorry. That's exactly why spammers look for open lists... Hit a lot of people with one address... === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Problems with mkraid
At 05:28 PM 4/7/00, Chris Fossenier wrote: >Hey folx, > >I'm trying to get mkraid to work on a TurboLinux server. I downloaded, >what I think is the most recent version of the mkraid utils. > >raidtools-19990824-0.90.tar.gz > >My kernel is > >2.2.14-3 > >I eventually got the stuff to compile and it worked "better" than the >shipping version (bundled with TL) of mkraid. The reason I needed a newer >version was so I could add the "failed-disk" parameter into my /etc/raidtab. > >Now mkraid is bombing out, saying the /dev/md0 is an invalid arguement. > >I have attached my /etc/raidtab, and a strace when I run mkraid. Sounds like you need to patch the kernel. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: What the hell is this?
At 12:51 PM 4/7/2000, Geoff Wheeler wrote: >David Cooley wrote: > > > > At 10:27 AM 4/7/2000, Geoff Wheeler wrote: > > >Are we being used? > > > > No, Spammed. > >Check the header. They're using the list to turn this stuff out. And unfortunately, the lists aren't "closed". Anyone posts to "[EMAIL PROTECTED]" and it's sent to all members, regardless of whether the sender is subscribed or not. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: What the hell is this?
At 10:27 AM 4/7/2000, Geoff Wheeler wrote: >Are we being used? No, Spammed. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: System Hangs -- Which Is Most Stable Kernel?
Is the PC overclocked in any way? I had troubles with my 2940U2W in both Windows and Linux when I overclocked the Front Side Bus from 100MHz to 103MHz. Seems the Adaptec cards can't handle *ANYTHING* over 33.3 MHz on the PCI bus. At 02:53 PM 3/27/2000, Jeff Hill wrote: >Thanks to everyone for the assistance. > >I did recompile the kernel with Translucent disabled (I don't know why >it is enabled by default?). Unfortunately, this has not affected the >problem. > >As for the Adaptec, I had checked on a hardware discussion list and >understood that, while some Adaptec's were problematic, the unit I >purchased (the 2940U2W with matching factory cables) was working well >for several Linux users. > >However, it seems to me from my limited experience that the Adaptec may >be the problem as it would fit the type of hanging that seems to occur >(no error messages, everything just freezes -- possibly waiting for the >Adaptec to send the data through). > >I am still unable to find any log or anyway of tracing the system hangs. >I may try debugging on the SCSI (haven't a clue how) for a few days >before trying to turn off RAID. Before buying another card (I have no >others), I'll hope some reconfiguration of the Adaptec will do the >trick. I hate to dump all that money down the drain. > >Thanks again to everyone for the assistance. > >Jeff Hill > >"m. allan noah" wrote: > > > > jeff- i am using 2.2.14 with mingo patch, and it is great. i have a > dozen or > > so boxes, 512meg, SMP pIII 450, ncr scsi, etc in this config. all are fine. > > > > it would be interesting to see if raid is the issue, or your adaptec (i am > > inclined to think the latter). > >< === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: superblock or the partition table is corrupt?
At 01:57 PM 3/27/2000, root wrote: >Thanks, >so I should be able to do the following without loss to date right? > > > > >1. umount /dev/md0 >2. raidstop /dev/md0 >3. change partition types on /dev/sda5 and /dev/sdb5 to fd (was linux) >4. raidstart /dev/md0 >5 mount -t ext2 /dev/md0 /mirrored_databases I don't know if re-writing the superblock with the type FD will preserve data or make the disk look empty... Better answered by someone with a little more experience than myself. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: superblock or the partition table is corrupt?
At 12:25 PM 3/27/2000, root wrote: >h. Looks like I forgot this step. I have a raid 1 setup under >RedHat 6.1's stock 2.2.12 kernel with raidtools already installed. >It works fine, a disk failed last weekend and I was able to recover >that disk while the array continued to function. > > >My question is this: Is it too late to run mke2fs on /dev/md0 >now that /dev/md0 contains data? >Also I dont see fd as an option for fdisk. If you needed to run mke2fs, you wouldn't be able to access the raid as a file system right now... That is the equivalent of a DOS format. Option FD doesn't show in the list on fdisk... you just have to select type then enter fd and return. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: superblock or the partition table is corrupt?
If dev/md0 is running, then the raid is running... you need to run mke2fs on it first to format the raid before fsck will work. At 06:45 PM 3/24/00, Jason Lin wrote: >I am trying to setup RAID 1 on RedHat6.1. > >"fsck /dev/md0" gives the following: > >Parallelizing fsck version 1.15 (18-Jul-1999) >e2fsck 1.15, 18-Jul-1999 for EXT2 FS 0.5b, 95/08/09 >The filesystem size (according to the superblock) is >757055 blocks >The physical size of the device is 757024 blocks >Either the superblock or the partition table is likely >to be corrupt! >Abort? >- >But the constituent disks have 757055 blocks each. >Should I do "mkraid --really-force /dev/md0" ? === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Software RAID with kernel 2.2.14
At 04:25 PM 3/23/2000, James Manning wrote: >[flag] > > And if I get the same msg when I try to build a raid 0? (my kernel > > is RAID patched: 2.2.14) > > > > [flag@Luxor flag]$ cat /proc/mdstat > > Personalities : [1 linear] [2 raid0] [3 raid1] [4 raid5] > > read_ahead not set > > md0 : inactive > > md1 : inactive > > md2 : inactive > > md3 : inactive > >allan's right, this is an unpatched kernel. Did you copy your vmlinuz or vmlinux and System.map to /boot or make pointers to them in /etc/lilo.conf?? === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Software RAID with kernel 2.2.14
I got the same errors until I increased my chunk size to 32K At 01:32 PM 3/23/2000, you wrote: >On Thu, 23 Mar 2000, m. allan noah wrote: > > > > mkraid: aborted, see the syslog and /proc/mdstat for potential clues > >And if I get the same msg when I try to build a raid 0? (my kernel >is RAID patched: 2.2.14) > >[flag@Luxor flag]$ cat /proc/mdstat >Personalities : [1 linear] [2 raid0] [3 raid1] [4 raid5] >read_ahead not set >md0 : inactive >md1 : inactive >md2 : inactive >md3 : inactive >[flag@Luxor flag]$ > >Maybe cause I'm doing it on the same device? (/dev/hda) >I know it's stupid to do a RAID on the same device, but i'm just doing >some test... > >This is my raidtab: > > raiddev /dev/md0 > raid-level 0 > nr-raid-disks 2 > persistent-superblock 0 > chunk-size 16 > device /dev/hda2 > raid-disk 0 > device /dev/hda4 > raid-disk 1 > > >Paolo === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Which patch? Kernel 2.2.14
My problem is the MVP3 chipset is not seen by linux even with this patch as ATA-66 compatible. My ATA-33 drive shows better transfer rates with tiobench than the ATA-66... hdparm won't allow me to set ATA-66 either... Tells me UDMA modes 3/4 are not available. In the Dmesg it identifies the chipset as "ATA/33" after the 82C596... At 02:50 AM 3/14/2000, Danilo Godec wrote: >On Mon, 13 Mar 2000, Clinton Bittel wrote: > > > I tried patching > > ide_2_2_14_2124_patch.gz > > raid-2_2.14-B1.gz > > And still cannot find a mention of the Ultra 66 or 33 > > when I go to recompile the kernel. Is it already > > built in?? > >ide_2_2_14_2124 takes care of ATA-66 drivers. They are not reffered to >as in general 'ATA-66', but are rather mentioned on per-chipset basis. > >CONFIG_BLK_DEV_HPT366 is one, for example... > > D. > === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: SV: SV: Could one disk cause all this, or is it a bug in Linux-RAID?
At 09:53 AM 3/6/2000, Johan Ekenberg wrote: > > >No. Like described in my original post, the crashes occur with > > >no warning at all. The system just goes down as when pulling the > > >power cord, and if the raid superblocks don't mess up to bad it > > >comes back up again. > > > > > > Could have a bad power supply, and the other item is the Motherboards > > on-board cache. > > Epox had a run of bad/marginal cache chips (had to get 2 > > replacement boards > > before they sent me a good one). > >Power-supply: Like stated before, I changed ALL hardware except the disks. >That means I also changed the power-supply. > >Cache: Is there any way to isolate and determine errors in the cache? The >problem now is that I don't know *what* keeps on biting me. If I could only >narrow it down to find the exact cause! To Eliminate Cache, just go into Bios setup during boot and disable external cache. If the crashes disappear, they were caused by the cache. Also, what CPU are you running? If it's an AMD, make sure that you disable caching of the BIOS in the setup also. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: SV: Could one disk cause all this, or is it a bug in Linux-RAID?
At 07:57 AM 3/6/2000, Johan Ekenberg wrote: > > > 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. > >No. Like described in my original post, the crashes occur with >no warning at all. The system just goes down as when pulling the >power cord, and if the raid superblocks don't mess up to bad it >comes back up again. Could have a bad power supply, and the other item is the Motherboards on-board cache. Epox had a run of bad/marginal cache chips (had to get 2 replacement boards before they sent me a good one). === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: are there archives or FAQ's?
Derek, You need to patch your kernel and re-compile it. If you downloaded the 0.90 raidtools, you need to patch the kernel. It was designed to run the 0.4X raidtools. At 07:11 PM 3/2/00, Derek Shaw wrote: >this is likely a problem that has been solved many times before, so >I'm hoping there's a FAQ with the answer somewhere. If not, > >I've just hit the first implementation snag with raidtools-0.90 on a >slackware 7 kernel 2.2.13. > >I've re-compiled the kernel to have md support at RAID-1 included in >the kernel. I believe I compiled and installed the raidtools >correctly (is there a better set of instructions than "unpack, >configure, compile and install the RAID tools" ?) These are >raidtools-19990824-0.90.tar.gz from the archive at >ftp.fi.kernel.org/pub/linux/daemons/raid/alpha/ > >As described in Jakob's HOWTO, I've set up an instance of /etc/raidtab >to try mirroring my two data drives (/dev/sdb1 and /dev/hdb1), which >have been created with mke2fs and fsck'd. > >mkraid /dev/md0 yields the message > >handling MD device /dev/md0 >analyzing super-block >disk 0: /dev/hdb1, 4217031kB, raid superblock at 4216960kB >disk 1: /dev/sdb1, 4217031kB, raid superblock at 4216960kB >mkraid: aborted, see the syslog and /proc/mdstat for potential clues > >but syslog is not recording anything to do with mkraid, and I have no >clue what the contents of /proc/mdstat mean. > >here's what's in /proc/mdstat >Personalities : [3 raid1] >read_ahead not set >md0 : inactive >md1 : inactive >md2 : inactive >md3 : inactive > > > > > >-- >Derek Shaw >Business Information Systems >Voice:250-885-2021 Fax:250-386-4060 > === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Raid patch for 2.2.14
At 12:07 PM 3/1/2000, Konstandinos A. Saipas wrote: >Sorry for asking for the same thing but accidentaly I erased the >email that had a url for raid patches for 2.2.14. >I am talking about the proper patch that is needed to use raid-tools 0.90 >with kernel 2.2.14. ( I am using rh 6.1 ). > >Thank you in advance, http://www.redhat.com/~mingo ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: RAID list
At 06:03 AM 2/29/2000, Manuel Fernandes wrote: >Hi All > >Sorry that I am bothering you about this but I am a little lost and a >little desperate. I have an new AMD athlon + RAID 0 on it. We have been >using raid0 since about 1996 or 1997 and I have just changed the setting >to use the new RAID which comes with RedHat linux 6.0 - kernel 2.2.5-15 >little realizing that they are very experimental and totally incompatible >with the original version. It also comes with raidtools 0.90. Now this >raid works OK but I have the >problem that I want to upgrade to a kernel that better supports the AMD >i.e. 2.2.14 but a raid patch does not exist for this kernel yet. When I >apply what seems to the the latest patch (for kernel 2.2.11) to >linux-2.2.14 I get a lot of errors and some reject files. You can get the proper patch from http://www.redhat.com/~mingo/ ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: FW: Raid installation trouble shooting. Please Help
As the error message points out, you need to type "mkraid --really-force /dev/md0" At 06:12 PM 2/11/00 -0500, Sahu, Devaraj wrote: >Please help me trouble shoot the RAID installation. > >I am trying to concatenate 2 scsi drives of 50 GB each using software RAID >level 1 in Linux 6.1. > > > >1. I created 2 raid partitions during installation on scsi drives a and >b. These are /dev/sda5 and /dev/sdb1 and of equal number of blocks. >2. created an /etc/raidtab file and rebooted the machine >3. did mkraid -f /dev/md0 >4. entered the command for making the file system > > >A log of relevant info is attached. > >As you can see, in step 4 I get a message "Invalid argument passed to ext2 >library while setting up superblock." > >What can I do to correct this situation? > >TIA > >Devaraj. > > > <> === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: rh 6.2 beta: raid upgrade possible?
At 09:23 AM 2/11/2000 -0500, Drenning Bruce wrote: >If anyone is looking at the red hat 6.2 beta, I'd like to hear whether you >could actually upgrade a raided system (w/o breaking & reconstructing, >obviously). The announcement seemed to indicate this was supported now. When I upgraded from RH6.0 sparc to RH 6.1 sparc, My raid 5 devices were untouched and came right up. No problems, No reconstructions. I'd assume that the path from 6.1 to 6.2 should be painless as well... But... Keep in mind that 6.2 IS BETA and as such it may not be stable enough for a production environment. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
RE: rh 6.2 beta: raid upgrade possible?
At 02:18 PM 2/11/2000 -0500, you wrote: >do you have root mirrored? Nope... /home/n5xmt and /home/ncdede === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
RE: New(?) IDE hardware RAID device
At 09:08 AM 2/9/2000 -0800, you wrote: >ok, I feel REALLY dumb now. I guess that's what I get for writing email >after 11:00 PM. >http://www.ami.com/hyperdisk/hyperdisk.html Tiger direct sells this... they have an internal card that goes between the on board controller and 2 drives to make them HW raid-1, and they have one that fits in a 5.25" drive bay with all the electronics in it... Both are about $250.00 for the controller... you still have to supply drives. Kind of steep considering Linux does it in software for free, and there are only 2 drives allowed to their raid card. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: mkraid aborting without any useful information
At 03:13 PM 2/7/2000 +, Carl L. Roy wrote: >I have just installed Mandrake 6.1 with mkraid version 0.90.0. The >Linux kernel that I am running is version 2.2.13-7mdk. When I attempt >to run mkraid, it aborts without returning any useful information. >How can I get more information on the cause of my problem? Here is >some information about my setup and the results that I receive. Carl, You need to patch your kernel source for the raidtools 0.90.x and recompile the kernel. Currently, all kernel source, unless it's part of a distribution like RH comes set up for raidtools 0.4x ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Newbie
At 12:08 PM 2/5/00 +0530, Ravi Dubey wrote: >Hi All !! > >I wish to develop a Raid Software on LINUX that will allow Raid Levels >0,1,2,5. Could anyone give me pointers as to where do I start, study >material on the net.. Maybe I'm missing something, but that's already part of Linux. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Unable to initialize a linear array
You need to specify a chunk size. Mine would fail building a RAID5 array unless I specified a chunk=32k or larger. Leaving it blank and it failed. At 03:35 PM 2/3/2000 -0600, [EMAIL PROTECTED] wrote: >Hello, > >I am having a problem initializing a linear array. I am using kernel >2.2.11 patched with raid0145-19990824-2.2.11 and >raidtools-19990824-0.90. > >My conf file looks like this: > >raiddev /dev/md0 > raid-level linear > nr-raid-disks 2 > persistent-superblock 1 > device /dev/sdb1 > raid-disk 0 > device /dev/sdc1 > raid-disk 1 > >The system is Redhat 6.1 and I was sure to remove the raidtools rpm >that came with the system before building and installing the raidtools >I got from ftp.dk.kernel.org. > >`mkraid -c /etc/raid.linear /dev/md0` with the correct force flag >gives the following output: > >handling MD device /dev/md0 >analyzing super-block >disk 0: /dev/sdb1, 17880313kB, raid superblock at 17880192kB >disk 1: /dev/sdc1, 17880313kB, raid superblock at 17880192kB >/dev/md0: Invalid argument > >I got this same error when using the stock Redhat kernel and raidtools >packages. I also made sure nothing was running in /proc/mdstat before >attempting to initialize the linear array. > >I compiled all the raid levels directly into the kernel and said 'no' >to the options Config.help said were unusable at the moment. > >/proc/mdstat looks like this: > >Personalities : [linear] [raid0] [raid1] [raid5] >read_ahead 1024 sectors >unused devices: > >Is there anything I am doing wrong or is linear just not supported >anymore because of a lack of interest? > >The system is going to be a web server where the average file size is >12k and there are between 20 and 50 of these files pulled from the >raid a second. > >I don't know much about raid or i/o performance but it seemed linear >may give better performance with these small file sizes and frequent >and distinct file accesses. I read ext2 distributes files across the >device in a semi-even way so two similar partitions in a linear raid >would potentially get close to the same usage. > >Is there anything I am missing or that I don't properly understand? > >Thanks in advance for any help! > >Jacob > === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Unable to initialize a linear array
One other question... Why did you downgrade RH6.1 to 2.2.11? It comes stock with 2.2.12, which is a better kernel IMHO. Also, Raid worked the first time with a RH6.1 install and NO patches or externally downloaded raidtools added. RH6.1 comes with the proper 0.9x raidtools and properly patched kernel. You need to specify a chunk size. Mine would fail building a RAID5 array unless I specified a chunk=32k or larger. Leaving it blank and it failed. At 03:35 PM 2/3/2000 -0600, [EMAIL PROTECTED] wrote: >Hello, > >I am having a problem initializing a linear array. I am using kernel >2.2.11 patched with raid0145-19990824-2.2.11 and >raidtools-19990824-0.90. > >My conf file looks like this: > >raiddev /dev/md0 > raid-level linear > nr-raid-disks 2 > persistent-superblock 1 > device /dev/sdb1 > raid-disk 0 > device /dev/sdc1 > raid-disk 1 > >The system is Redhat 6.1 and I was sure to remove the raidtools rpm >that came with the system before building and installing the raidtools >I got from ftp.dk.kernel.org. > >`mkraid -c /etc/raid.linear /dev/md0` with the correct force flag >gives the following output: > >handling MD device /dev/md0 >analyzing super-block >disk 0: /dev/sdb1, 17880313kB, raid superblock at 17880192kB >disk 1: /dev/sdc1, 17880313kB, raid superblock at 17880192kB >/dev/md0: Invalid argument > >I got this same error when using the stock Redhat kernel and raidtools >packages. I also made sure nothing was running in /proc/mdstat before >attempting to initialize the linear array. > >I compiled all the raid levels directly into the kernel and said 'no' >to the options Config.help said were unusable at the moment. > >/proc/mdstat looks like this: > >Personalities : [linear] [raid0] [raid1] [raid5] >read_ahead 1024 sectors >unused devices: > >Is there anything I am doing wrong or is linear just not supported >anymore because of a lack of interest? > >The system is going to be a web server where the average file size is >12k and there are between 20 and 50 of these files pulled from the >raid a second. > >I don't know much about raid or i/o performance but it seemed linear >may give better performance with these small file sizes and frequent >and distinct file accesses. I read ext2 distributes files across the >device in a semi-even way so two similar partitions in a linear raid >would potentially get close to the same usage. > >Is there anything I am missing or that I don't properly understand? > >Thanks in advance for any help! > >Jacob === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: 2.3.x ??
At 09:37 AM 2/2/2000 -0500, Edward Schernau wrote: >Is raid 0.90 in the 2.3 kernels, or do you still need to patch? >Sorry if this has been discussed before... Still need to patch... For whatever reasons, the distributed raw kernel source isn't up to date for raid... Kernels from Redhat (RPM's) for updates come with the patch added though... Not sure about other distro's. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Reconstruction questions
At 05:34 PM 2/2/2000 +0200, you wrote: >And someone mentioned ,that make bzImage doesn't work. Why? Becaise Kernels on SPARC boxes aren't limited to 640K of DOS memory like a PC. It's in the documentation of the Kernel Source in all the SPARC linux distro's. You have to use "make vmlinux" ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: mkraid: aborted
You need to patch your kernel and re-compile for the new raid code. You are running raidtools 0.9x with a kernel that only has support for 0.4x and lower. At 02:09 PM 2/2/2000 +0200, Antanas Masevicius wrote: >hello, > >i've set up a few partitions in order to test raid1, but following error >ocures: > >DESTROYING the contents of /dev/md0 in 5 seconds, Ctrl-C if unsure! >handling MD device /dev/md0 >analyzing super-block >disk 0: /dev/hda4, 8032kB, raid superblock at 7936kB >disk 1: /dev/hdd2, 8032kB, raid superblock at 7936kB >mkraid: aborted, see the syslog and /proc/mdstat for potential clues. > >my /proc/mdstat looks like: >Personalities : [3 raid1] >read_ahead not set >md0 : inactive >md1 : inactive >md2 : inactive >md3 : inactive > >and /var/log/syslog says nothing. > > > >Antanas Masevicius Kaunas University of Technology >Studentu 48a-101 Computer Center >LT-3028 Kaunas LITNET NOC UNIX Systems Administrator >Lithuania E-mail: [EMAIL PROTECTED] === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Raid 0 problems
You need the patch for the 2.2.14 kernel... http://www.redhat.com/~mingo/ At , Jens Klaas wrote: >Hi Gang, >I use the 2.2.11 kernel with the raid0145-19990824-2.2.11 patch. >It works fine as long as I don't let multiple user on the system. >Heavy load is not the problem, more the concurrent access. :( >The box crashed without any error message in any log file. > >I compiled the 2.2.14 kernel without any patch. Now I can't start my raid, >even if the md driver are available. > >Is raid0 with the patch and the kernel supported raid0 not the same format? > >In the mkraid man page I read somethink about the old format. How can I get >more infos about the new format. > >cu >Jens > > ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: resync process doesn't terminate
At 06:22 PM 1/24/00 -0500, James Manning wrote: >[ Monday, January 24, 2000 ] W. Scott Wilburn wrote: > > Upon reboot, two [raid1syncd] processes appear, as expected. > > However, they remain after resync is complete. > >IIRC the raid5syncd had the same issue and it was fixed... most >likely it'll be a very similar fix so if anyone remembers either >the fix or which patch was first with the fix, this should be >simple to correct. > >They're harmless, though, and shouldn't be taking any CPU or other resources. My raid5syncd stay resident with a nice of -20 with the latest raid patches etc. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: resync process doesn't terminate
At 12:17 PM 1/24/00 -0700, you wrote: >Feel free to ignore this message if it isn't useful. > >I have two raid-1 paritions / and /home. > >I have recently had two unplanned reboots one a power failure, one a real >crash (first one in 3 years of using Linux!) > >Upon reboot, two [raid1syncd] processes appear, as expected. >However, they remain after resync is complete. That's normal. They stay resident with a nice of -20. If anything should happen with the raid array (something corrupt) they go back into action. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: crash/instability
At 08:13 PM 1/24/00 -0500, Edward Schernau wrote: >Note the crosspost. > >Ive had occasional, maybe 6 lockups since I bought my ABit BP6/dual >system, a month ago. > >Since installing the raid patches on my hpt366-patched kernel last >week, its locked up much more often, tonight 4 times. > >I left it running all day with 2 RC5 clients running, and it was fine. >Within 2 hours of starting X, loading WP8, netscape, etc., it died 3 >times. > >This seems more frequent since I patched for RAID. Try it without netscape... NS crashes for no apparent reason on mine, doesn't bring down the system, but kills X ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: RAID5 and 2.2.14
I took the patch I grabbed at work on a SUN box and loaded it... it was 60K smaller than the one I was loading last night. Patched a fresh 2.2.14 kernel with no problems and the raid is up and running! Thanks for everyone's help, and Damn you, Bill Gates for your Kludged 8 bit GUI OS! At 10:23 PM 1/24/00 +0800, Gary Allpike wrote: >I have put up a pre-patched kernel source at : > >http://spice.indigo.net.au/linux-2.2.14+raid-2.2.14-B1.tar.bz2 ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Raid results
Well, Ultra2, SMP running (dual 300MHZ CPU's), 256M ram, /home/n5xmt is 6 4.2G drives in half of a SUN D1000 run from a QlogicPTI SCSI board, /home/ncdede is the other 6 4.2G drives on it's own QlogicPTI controller. Here are Bonnie and TIOTEST results: [root@bigdaddy bigbonnie]# ./bonnie -d /home/n5xmt -s 100 -v 10 -m Ultra2 File '/home/n5xmt/Bonnie.737', size: 104857600, volumes: 10 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seek numbers calculated on first volume only Seeker 2...Seeker 1...Seeker 3...start 'em...done...done...done... ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU Ultra2 10* 100 3367 99.8 22063 35.4 11175 37.3 3944 97.3 27212 29.8 312.7 8.9 [root@bigdaddy bigbonnie]# [root@bigdaddy tiotest-0.16]# sh tiobench.sh 1000 /home/n5xmt Found tiotest in ./tiotest Testing with 1 threads...Done Testing with 2 threads...Done Testing with 4 threads...Done Testing with 8 threads...Done Results for 1 threads: 1048576000 bytes written in 51.920 seconds, 19.26040 MBytes/Sec 1048576000 bytes readin 37.410 seconds, 26.73082 MBytes/Sec 4000 seeks in 31.800 seconds, 125.78616 Seeks/Sec Results for 2 threads: 1048576000 bytes written in 60.440 seconds, 16.54533 MBytes/Sec 1048576000 bytes readin 46.190 seconds, 21.64971 MBytes/Sec 4000 seeks in 19.030 seconds, 210.19443 Seeks/Sec Results for 4 threads: 1048576000 bytes written in 59.060 seconds, 16.93193 MBytes/Sec 1048576000 bytes readin 49.810 seconds, 20.07629 MBytes/Sec 4000 seeks in 12.660 seconds, 315.95577 Seeks/Sec Results for 8 threads: 1048576000 bytes written in 61.140 seconds, 16.35590 MBytes/Sec 1048576000 bytes readin 56.920 seconds, 17.56852 MBytes/Sec 4000 seeks in 10.140 seconds, 394.47732 Seeks/Sec Tests done. [root@bigdaddy tiotest-0.16]# [root@bigdaddy tiotest-0.16]# sh tiobench.sh 1000 /home/ncdede Found tiotest in ./tiotest Testing with 1 threads...Done Testing with 2 threads...Done Testing with 4 threads...Done Testing with 8 threads...Done Results for 1 threads: 1048576000 bytes written in 45.860 seconds, 21.80549 MBytes/Sec 1048576000 bytes readin 36.480 seconds, 27.41228 MBytes/Sec 4000 seeks in 25.770 seconds, 155.21925 Seeks/Sec Results for 2 threads: 1048576000 bytes written in 55.390 seconds, 18.05380 MBytes/Sec 1048576000 bytes readin 44.700 seconds, 22.37136 MBytes/Sec 4000 seeks in 15.730 seconds, 254.29116 Seeks/Sec Results for 4 threads: 1048576000 bytes written in 54.430 seconds, 18.37222 MBytes/Sec 1048576000 bytes readin 48.960 seconds, 20.42484 MBytes/Sec 4000 seeks in 10.600 seconds, 377.35849 Seeks/Sec Results for 8 threads: 1048576000 bytes written in 54.640 seconds, 18.30161 MBytes/Sec 1048576000 bytes readin 55.180 seconds, 18.12251 MBytes/Sec 4000 seeks in8.670 seconds, 461.36101 Seeks/Sec Tests done. [root@bigdaddy tiotest-0.16]# ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: RAID5 and 2.2.14
Oops... I meant fresh 2.2.14 kernel.org source. At 10:33 PM 1/23/2000 -0500, David Cooley wrote: >Here's what I get when patching against a fresh 2.2.13-1.3.0 kernel source > > > >Where'd you get your source? >I downloaded mine from ftp.kernel.org and it's 2.2.14-1.3.0 > > >At 11:08 AM 1/24/00 +0800, Gary Allpike wrote: > > > > >======= >David Cooley N5XMT Internet: [EMAIL PROTECTED] >Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 >We are Borg... Prepare to be assimilated! >=== === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: RAID5 and 2.2.14
I just re-downloaded the Kernel source and patch while at work on a SUN box running Solaris 2.6... I'll get this too, but will play with the patching first to see if it was windows trashing the patch on the download. Thanks! Dave At 10:23 PM 1/24/2000 +0800, Gary Allpike wrote: >I have put up a pre-patched kernel source at : > >http://spice.indigo.net.au/linux-2.2.14+raid-2.2.14-B1.tar.bz2 > >regards > > >Gary Allpike >[EMAIL PROTECTED] >http://www.linux.org.au > > >On Mon, 24 Jan 2000, David Cooley wrote: > > > Oops... I meant fresh 2.2.14 kernel.org source. > > > > > > At 10:33 PM 1/23/2000 -0500, David Cooley wrote: > > >Here's what I get when patching against a fresh 2.2.13-1.3.0 kernel source > > > > > > > > > > > >Where'd you get your source? > > >I downloaded mine from ftp.kernel.org and it's 2.2.14-1.3.0 > > > > > > > > >At 11:08 AM 1/24/00 +0800, Gary Allpike wrote: > > > > > > > > > > > > > > >=== > > >David Cooley N5XMT Internet: [EMAIL PROTECTED] > > >Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 > > >We are Borg... Prepare to be assimilated! > > >=== > > > > === > > David Cooley N5XMT Internet: [EMAIL PROTECTED] > > Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 > > We are Borg... Prepare to be assimilated! > > === > > === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: RAID5 and 2.2.14
At 08:06 PM 1/23/00 -0800, Michael Robinton wrote: > > 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 >all hunks should go in OK -- did for me Since I put his patch in /usr/src I used patch -p0 raid-2.2.14-b1 ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: RAID5 and 2.2.14
inear.h.rej patching file `linux/drivers/block/md.c' Hunk #1 FAILED at 1. Hunk #2 FAILED at 22. Hunk #3 FAILED at 3032. Hunk #4 FAILED at 3442. Hunk #5 FAILED at 3831. Hunk #6 FAILED at 3858. Hunk #7 FAILED at 3886. 7 out of 7 hunks FAILED -- saving rejects to linux/drivers/block/md.c.rej patching file `linux/drivers/block/ll_rw_blk.c' Hunk #1 FAILED at 21. Hunk #2 FAILED at 52. Hunk #3 FAILED at 429. Hunk #4 FAILED at 689. Hunk #5 FAILED at 709. 5 out of 5 hunks FAILED -- saving rejects to linux/drivers/block/ll_rw_blk.c.rej patching file `linux/drivers/block/raid0.c' Hunk #1 FAILED at 1. Hunk #2 FAILED at 17. Hunk #3 FAILED at 221. 3 out of 3 hunks FAILED -- saving rejects to linux/drivers/block/raid0.c.rej patching file `linux/drivers/block/raid1.c' Hunk #1 FAILED at 1. Hunk #2 FAILED at 15. Hunk #3 FAILED at 69. Hunk #4 FAILED at 99. Hunk #5 FAILED at 106. Hunk #6 FAILED at 131. Hunk #7 FAILED at 143. Hunk #8 FAILED at 203. Hunk #9 FAILED at 271. Hunk #10 FAILED at 284. Hunk #11 FAILED at 387. Hunk #12 FAILED at 446. Hunk #13 FAILED at 864. Hunk #14 FAILED at 1211. Hunk #15 FAILED at 1229. 15 out of 15 hunks FAILED -- saving rejects to linux/drivers/block/raid1.c.rej patching file `linux/drivers/block/raid5.c' Hunk #1 FAILED at 1. Hunk #2 FAILED at 14. Hunk #3 FAILED at 32. Hunk #4 FAILED at 45. Hunk #5 FAILED at 62. Hunk #6 FAILED at 115. Hunk #7 FAILED at 124. Hunk #8 FAILED at 147. Hunk #9 FAILED at 164. Hunk #10 FAILED at 179. Hunk #11 FAILED at 328. Hunk #12 FAILED at 342. Hunk #13 FAILED at 364. Hunk #14 FAILED at 401. Hunk #15 FAILED at 409. Hunk #16 FAILED at 478. Hunk #17 FAILED at 529. Hunk #18 FAILED at 543. Hunk #19 FAILED at 582. Hunk #20 FAILED at 593. Hunk #21 FAILED at 601. Hunk #22 FAILED at 667. Hunk #23 FAILED at 695. Hunk #24 FAILED at 717. Hunk #25 FAILED at 738. Hunk #26 FAILED at 760. Hunk #27 FAILED at 775. Hunk #28 FAILED at 788. Hunk #29 FAILED at 899. Hunk #30 FAILED at 951. Hunk #31 FAILED at 977. Hunk #32 FAILED at 1006. Hunk #33 FAILED at 1026. Hunk #34 FAILED at 1074. Hunk #35 FAILED at 1087. Hunk #36 FAILED at 1121. Hunk #37 FAILED at 1147. Hunk #38 FAILED at 1180. Hunk #39 FAILED at 1193. Hunk #40 FAILED at 1215. Hunk #41 FAILED at 1224. Hunk #42 FAILED at 1247. Hunk #43 FAILED at 1264. Hunk #44 FAILED at 1284. Hunk #45 FAILED at 1303. Hunk #46 FAILED at 1334. Hunk #47 FAILED at 1343. Hunk #48 FAILED at 1391. Hunk #49 FAILED at 1460. Hunk #50 FAILED at 2072. 50 out of 50 hunks FAILED -- saving rejects to linux/drivers/block/raid5.c.rej patching file `linux/drivers/block/translucent.c' patching file `linux/drivers/block/xor.c' patching file `linux/drivers/block/hsm.c' patching file `linux/arch/i386/defconfig' Hunk #1 FAILED at 93. 1 out of 1 hunk FAILED -- saving rejects to linux/arch/i386/defconfig.rej patching file `linux/arch/sparc64/kernel/sparc64_ksyms.c' Hunk #1 FAILED at 81. Hunk #2 FAILED at 297. 2 out of 2 hunks FAILED -- saving rejects to linux/arch/sparc64/kernel/sparc64_ksyms.c.rej patching file `linux/Documentation/Configure.help' Hunk #1 FAILED at 956. Hunk #2 FAILED at 1041. 2 out of 2 hunks FAILED -- saving rejects to linux/Documentation/Configure.help.rej [root@bigdaddy src]# === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
RE: Welcome to linux-raid
Clay, I downloaded the 2.2.14 source and the patch. Patch applies fine at first, then fails miserably in the last 75-100 hunks. downloaded again just in case... same thing. Compiled the kernel anyway and no go. Won't recognize my raid and it appears the same as the 0.90 tools without the patch in earlier kernels... looks like it will start the raid, then gives the message to see /proc/mdstat and the syslog, but no raid. Errors in the system log are: Oops ! md0 not running, giving up ! Bad md_map in ll_rw_block EXT2-fs: unable to read superblock Oops ! md1 not running, giving up ! Bad md_map in ll_rw_block EXT2-fs: unable to read superblock Mkraid --really-force /dev/md0 gives: [root@bigdaddy /root]# mkraid --really-force /dev/md0 DESTROYING the contents of /dev/md0 in 5 seconds, Ctrl-C if unsure! handling MD device /dev/md0 analyzing super-block disk 0: /dev/sdc1, 4189320kB, raid superblock at 4189248kB disk 1: /dev/sdd1, 4189320kB, raid superblock at 4189248kB disk 2: /dev/sde1, 4189320kB, raid superblock at 4189248kB disk 3: /dev/sdf1, 4189320kB, raid superblock at 4189248kB disk 4: /dev/sdg1, 4189320kB, raid superblock at 4189248kB disk 5: /dev/sdh1, 4189320kB, raid superblock at 4189248kB mkraid: aborted, see the syslog and /proc/mdstat for potential clues. and that's all she wrote. If I reboot to 2.2.12, raid starts and runs just fine. At 12:12 PM 1/8/00 -0700, Jones, Clay wrote: >Actually, that's incorrect (Sorry David). For the 2.2.14 kernel, Ingo >Molinar has released a specific patch. He sent it out to the board a >couple days ago. > ><http://www.redhat.com/~mingo/raid-2.2.14-B1>http://www.redhat.com/~mingo/r >aid-2.2.14-B1 > >Get that patch, apply it to the 2.2.14 kernel, then raid 0.90 will be >available. There are compatability problems between 2.2.14 and the >raid0145 2.2.11 patch. > >Clay > >-Original Message- >From: David Cooley [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] >Sent: Saturday, January 08, 2000 12:01 PM >To: Antanas Masevicius; [EMAIL PROTECTED] >Subject: Re: Welcome to linux-raid > >You MUST apply the 2.2.11 raid patch before raidtools 0.90 will work with >the kernel properly. >Answer N to the errors > >At 08:13 PM 1/8/00 +0200, Antanas Masevicius wrote: > > >Hello there, > > > >I face'd the promblem: > > > ># mkraid /dev/md0 > >handling MD device /dev/md0 > >analyzing super-block > >disk 0: /dev/hdc1, 8032kB, raid superblock at 7936kB > >disk 1: /dev/hdd2, 8032kB, raid superblock at 7936kB > >mkraid: aborted, see the syslog and /proc/mdstat for potential clues. > > > >and syslog shows nothing. > > > >/proc/mdstat contains: > >Personalities : [3 raid1] > >read_ahead not set > >md0 : inactive > >md1 : inactive > >md2 : inactive > >md3 : inactive > > > >as it has to before the md0 creation. > > > >raidtools: raidtools-0.90 > >i'm using linux-2.2.14 kernel version. ( any patch for this kernel ?) > >Debian 2.2 glibc 2.1 > >also tested on Debian 2.1 glibc2 > > > >i've tried diferent sets of HD's and diferent sets of partitions. Nothing > >helps. > > > >Any suggestions ? > > > >thanx > > > >======== > > > >Antanas Masevicius Kaunas University of Technology > >Studentu 48a-101 Computer Center > >LT-3028 Kaunas LITNET NOC UNIX Systems Administrator > >Lithuania E-mail: [EMAIL PROTECTED] > > > >=== >David Cooley N5XMT Internet: [EMAIL PROTECTED] >Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 >We are Borg... Prepare to be assimilated! >=== === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: RAID5 and 2.2.14
Where'd you get your source? I downloaded mine from ftp.kernel.org and it's 2.2.14-1.3.0 At 11:08 AM 1/24/00 +0800, Gary Allpike wrote: >David, > >I think you may have a kernel that has had other patches applied to it. > >2.2.14 and the associated patch worked fine for me, the patch applied with >no rejects. > > >regards > > >Gary Allpike >[EMAIL PROTECTED] >http://www.linux.org.au > > >On Sun, 23 Jan 2000, David Cooley wrote: > > > 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 > > hunks. Tried a compile and booted to the new kernel... none of the raid > > functions work, and it says it found the raid superblock, but it has > > errors. Boot back to 2.2.12 kernel and raid is fine. > > > > === > > David Cooley N5XMT Internet: [EMAIL PROTECTED] > > Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 > > We are Borg... Prepare to be assimilated! > > === > > === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
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 hunks. Tried a compile and booted to the new kernel... none of the raid functions work, and it says it found the raid superblock, but it has errors. Boot back to 2.2.12 kernel and raid is fine. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
2.2.14 sparc...
Hi All, Am trying to upgrade the Kernel on my Ultra2 running RH 6.1 It appears the redhat kernel source has part of Mingo's raid patch for 2.2.14 applied, but not all. I then downloaded a complete tarball of the 2.2.14 kernel source from kernel.org and mingo's patch appeared to apply at first, then failed miserably on about the last 30 hunks. Any hints on this??? Thanks, Dave ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Linux software status?
At 04:12 PM 1/21/00 +0800, ZhouYouchun wrote: >Hi, > I just subscribed the Linux-raid mailing list. > Now I want to know the detailed status of linux software-raid (raid >levels,performance,stability,how it behaves compared with other >software-raid implementation) and whether it is suitable for enterprise >enviroment. Could you give me some suggestions about where i can find my >the information i needed? Well, Personal experience here... I have a SUN Ultra2 with Dual 300MHz CPU's and 512M ram running Raid 5 on a SUN D1000 with 12 4.2G drives. I split them into 2 groups of 6 (one for me, one for the wife) and have 2 20G md devices. It's been running this way since October with only 2 reboots, and one was for upgrading from RH6.0 to RH6.1 I'm running SAMBA on it for connectivity to the Win machines in my house. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Welcome to linux-raid
You MUST apply the 2.2.11 raid patch before raidtools 0.90 will work with the kernel properly. Answer N to the errors At 08:13 PM 1/8/00 +0200, Antanas Masevicius wrote: >Hello there, > >I face'd the promblem: > ># mkraid /dev/md0 >handling MD device /dev/md0 >analyzing super-block >disk 0: /dev/hdc1, 8032kB, raid superblock at 7936kB >disk 1: /dev/hdd2, 8032kB, raid superblock at 7936kB >mkraid: aborted, see the syslog and /proc/mdstat for potential clues. > >and syslog shows nothing. > >/proc/mdstat contains: >Personalities : [3 raid1] >read_ahead not set >md0 : inactive >md1 : inactive >md2 : inactive >md3 : inactive > >as it has to before the md0 creation. > >raidtools: raidtools-0.90 >i'm using linux-2.2.14 kernel version. ( any patch for this kernel ?) >Debian 2.2 glibc 2.1 >also tested on Debian 2.1 glibc2 > >i've tried diferent sets of HD's and diferent sets of partitions. Nothing >helps. > >Any suggestions ? > >thanx > > > >Antanas Masevicius Kaunas University of Technology >Studentu 48a-101 Computer Center >LT-3028 Kaunas LITNET NOC UNIX Systems Administrator >Lithuania E-mail: [EMAIL PROTECTED] > === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Bug in raid5.c line 659
gt;Jan 8 05:22:43 gulag kernel: D 1: DISK >Jan 8 05:22:43 gulag kernel: D 2: DISK >Jan 8 05:22:43 gulag kernel: D 3: DISK >Jan 8 05:22:43 gulag kernel: D 4: DISK >Jan 8 05:22:43 gulag kernel: D 5: DISK >Jan 8 05:22:43 gulag kernel: D 6: DISK >Jan 8 05:22:43 gulag kernel: D 7: DISK >Jan 8 05:22:43 gulag kernel: D 8: DISK >Jan 8 05:22:43 gulag kernel: D 9: DISK >Jan 8 05:22:43 gulag kernel: D 10: DISK >Jan 8 05:22:43 gulag kernel: D 11: DISK >Jan 8 05:22:43 gulag kernel: THIS: DISK >Jan 8 05:22:43 gulag kernel: md2: array superblock: >Jan 8 05:22:43 gulag kernel: SB: (V:0.90.0) >ID:<018c4874...> CT:37f09a04 >Jan 8 05:22:43 gulag kernel: L5 S12377984 ND:3 RD:3 md2 LO:2 CS:32768 >Jan 8 05:22:43 gulag kernel: UT:387629a7 ST:0 AD:2 WD:2 FD:1 SD:0 >CSUM:1bd90f16 E:000e >Jan 8 05:22:43 gulag kernel: D 0: DISK >Jan 8 05:22:43 gulag kernel: D 1: DISK >Jan 8 05:22:43 gulag kernel: D 2: DISK >Jan 8 05:22:43 gulag kernel: D 3: DISK >Jan 8 05:22:43 gulag kernel: D 4: DISK >Jan 8 05:22:43 gulag kernel: D 5: DISK >Jan 8 05:22:43 gulag kernel: D 6: DISK >Jan 8 05:22:43 gulag kernel: D 7: DISK >Jan 8 05:22:43 gulag kernel: D 8: DISK >Jan 8 05:22:43 gulag kernel: D 9: DISK >Jan 8 05:22:43 gulag kernel: D 10: DISK >Jan 8 05:22:43 gulag kernel: D 11: DISK >Jan 8 05:22:43 gulag kernel: THIS: DISK >Jan 8 05:22:43 gulag kernel: rdev hde4: O:hde4, SZ:12396288 F:0 DN:2 >rdev superblock: >Jan 8 05:22:43 gulag kernel: SB: (V:0.90.0) >ID:<018c4874...> CT:37f09a04 >Jan 8 05:22:43 gulag kernel: L5 S12377984 ND:3 RD:3 md2 LO:2 CS:32768 >Jan 8 05:22:43 gulag kernel: UT:387629a7 ST:0 AD:2 WD:2 FD:1 SD:0 >CSUM:1bdbbbd3 E:000e >Jan 8 05:22:43 gulag kernel: D 0: DISK >Jan 8 05:22:43 gulag kernel: D 1: DISK >Jan 8 05:22:43 gulag kernel: D 2: DISK >Jan 8 05:22:43 gulag kernel: D 3: DISK >Jan 8 05:22:43 gulag kernel: D 4: DISK >Jan 8 05:22:43 gulag kernel: D 5: DISK >Jan 8 05:22:43 gulag kernel: D 6: DISK >Jan 8 05:22:43 gulag kernel: D 7: DISK >Jan 8 05:22:43 gulag kernel: D 8: DISK >Jan 8 05:22:43 gulag kernel: D 9: DISK >Jan 8 05:22:43 gulag kernel: D 10: DISK >Jan 8 05:22:43 gulag kernel: D 11: DISK >Jan 8 05:22:43 gulag kernel: THIS: DISK >Jan 8 05:22:43 gulag kernel: rdev hdc4: O:hdc4, SZ: F:1 DN:1 no >rdev superblock! >Jan 8 05:22:43 gulag kernel: rdev hda4: O:hda4, SZ:12377984 F:0 DN:0 >rdev superblock: >Jan 8 05:22:43 gulag kernel: SB: (V:0.90.0) >ID:<018c4874...> CT:37f09a04 >Jan 8 05:22:43 gulag kernel: L5 S12377984 ND:3 RD:3 md2 LO:2 CS:32768 >Jan 8 05:22:43 gulag kernel: UT:387629a7 ST:0 AD:2 WD:2 FD:1 SD:0 >CSUM:1bd1 E:000e >Jan 8 05:22:43 gulag kernel: D 0: DISK >Jan 8 05:22:43 gulag kernel: D 1: DISK >Jan 8 05:22:43 gulag kernel: D 2: DISK >Jan 8 05:22:43 gulag kernel: D 3: DISK >Jan 8 05:22:43 gulag kernel: D 4: DISK >Jan 8 05:22:43 gulag kernel: D 5: DISK >Jan 8 05:22:43 gulag kernel: D 6: DISK >Jan 8 05:22:43 gulag kernel: D 7: DISK >Jan 8 05:22:43 gulag kernel: D 8: DISK >Jan 8 05:22:43 gulag kernel: D 9: DISK >Jan 8 05:22:43 gulag kernel: D 10: DISK >Jan 8 05:22:43 gulag kernel: D 11: DISK >Jan 8 05:22:43 gulag kernel: THIS: DISK >Jan 8 05:22:43 gulag kernel:** > > === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Raid Patch
At 10:03 AM 1/4/2000 +0100, Sebastian Lemke wrote: >Hello everbody, > >a few month ago I patched my Linux 2.2.11 Kernel with the Raidpatch0145 >und Raidtools found at >ftp://ftp.kernel.org/pub/linux/daemons/raid/alpha/. >But now I mentioned that there is a new Kernel 2.2.13 but the Raid >Patches are not available for this kernelversion. Can I use the "old" >raidpatches for the 2.2.13 Kernel or is there a new version of the >patches. > >Sorry for my bad English:-) Use the old 2.2.11 patchen and answer N to the rejects ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
RE: swapping on raid
Part of the problem you may be seeing is SCSI itself. You pull an active SCSI data cable on a non-hot swappable controller/drive and the controller will hang the SCSI and CPU busses the next time it accesses the controller. At 03:42 PM 1/1/2000 -0500, you wrote: >the linux kernel stripes swap writes across multiple swap partitions of the >same priority. striping (effectively raid0) provides NO reliability in case of >disk failure. this is what the original poster was asking about. > >to aswer the original question, i have twice tried to make swap on raid1, >which can be sucessfully done. the system swaps to the raid just fine. > >HOWEVER- i pull the scsi data cable or power cable and the system will hang >cold on the next swap write. > >i am using tekram dc390f (ncr53c875) scsi controller, and older 9gig >full-height seagate barracudas. > >i have not had a chance to wrap my mind around the problem in question, and >the linux buff/cache code has a bit of a learning curve, but from practical >experience, i do not trust swap on raid 1, and wont use it. esp. since it >seems to have little to do with re-construction, and more to do with the death >of a disk, the very thing we want to prevent... ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Don't try this at home!
Jim, If these are SCSI disks, removing power can cause a MULTITUDE of problems you won't see if the SCSI connection to a drive fails. Unless the drives and controller aren't the original SCSI 1 8 bit bus, the termination has power supplied by the drive. Removing the power kills the termination and will lleave the bus in an undetermined state, with an unknown load on the bus as well. I am going to place a guess and assume the 2nd drive that got kicked was the next furthest drive away from the controller than the one you unplugged. This would be expected. If you power on the drives again and boot linux, it SHOULD correctly restore the data... that is unless the raid was active when you unplugged the drive, as SCSI drives have a large RAM cache that probably got corrupted, and the data was never written to the 2 drives. At 04:14 PM 12/31/1999 +, you wrote: >I've been experimenting with my 4 disk Raid5 setup for a few weeks now and >been impressed - so far. > >Today, I sucumbed to the temptation of of simulating a disk failure (or >more accurately a power supply failure to a disk), by 'hot' unplugging its >power lead. Nothing appeared to happen at first - mdstat reported that all >disks were working. Then the system stopped responding to console commands >- not even to a shutdown.'Never mind' I thought, I'll power cycle and when >it fires up again the array will get reconstructed and all will be fine. >However, on restarting, md reported that _2_ disks were non-fresh and were >kicked from the array. This left only 2 disks for reconstruction - and the >system gave up with a kernel panic. I'm now left with a system that I >can't do anything with except a reinstallation from scratch. > >Where did I go wrong - what strategy should be adopted in such a >situation? It seems to me that cutting the power to a disk is a reasonable >test - simulating a faulty connection. Should I have waited longer before >shutting the power off to the system - and was this the reason that the >2nd disk went down? If I'd had a spare disk in the array, would it have >reconstructed O.K.? > >Now - this is the interesting one - if the system had _not_ been Raid5 I >could probably have done the same thing and still ended up with a useable >system. In likelyhood, all that would have happened is that the fs would >have been marked as dirty and a fschk carried out at next reboot. This >suggests that Raid5 _can_ be more fragile than a non Raid setup. > >Regards: Jim Ford === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: mkraid problem
At 01:54 AM 12/31/1999 +0100, Luca Berra wrote: > > > > You need to patch the kernel for the 0.9x raidtools. I believe Mandrake's > > kernels are still at 0.4x and lower for kernel support, with 0.9x > raidtools > > included (why they don't pre-patch the kernel source to support the > > raidtools they include is beyond me and why I won't use mandrake! What > > other incompatabilities do they include!) > >This as been fixed in the last kernel update from mandrake some months ago. >If you use a distribution and don't look at the updates you deserve what >you get Which is why I use RH 6.1, all the updates are there, and I custom compile my kernels... I only use the "canned" kernels for the initial boot and install. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: mkraid problem
At 12:07 PM 12/30/1999 -0500, you wrote: >I'm running Mandrake 6.1 with a couple of 9GB IBM U2 SCSI Drives off of >an Adaptec 7890 controller. I've been trying for a while now (a couple >of days) to get several of the partitions on the drives to be RAID-1 . >However when I try and run mkraid I get the following: You need to patch the kernel for the 0.9x raidtools. I believe Mandrake's kernels are still at 0.4x and lower for kernel support, with 0.9x raidtools included (why they don't pre-patch the kernel source to support the raidtools they include is beyond me and why I won't use mandrake! What other incompatabilities do they include!) ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Help needed, disk failure on _old_ RAID-array
With the boot disk, if it pauses and asks for parameters you can state "root=/dev/sdb1" after you copy everything over. Once booted, copy it back to the new drive and all should be well. At 05:39 PM 12/20/1999 +0200, Simo Varis wrote: >I got nice suprise, a disk on old (0.36.6) RAID1 array is going to fail, >it gives read errors on non-raid partition so I'm going to get it >replaced. Now, the "nice" part is that failing partition happens to be >root partition. There hasn't been any major changes in the system since >setup (which was in July 97, no raid boot available back then) so it's >been easy enough to copy changed files from sda1 to sdb1. > >Then, next interesting feature is that there's a boot floppy (kernel >only, created with make zdisk I believe), so at least there's no lilo >which could get confused if order of drives changes. > >So, what would be the best way (other than full DAT backup) to replace >the disk and get system back as soon as possible? Can I move sdb to be >sda and install new disk as sdb, and the reconstruct RAID or does sdb >must stay as sdb? Howto does not help too much, it seems to refer to >newer RAID than one on that computer. > >I need to know as much as possible in advance, since the computer has >on-site warranty and they just throw new one in and take bad one and >leave... No time to put old one back in if something happens. > >-- >Simo Varis -- [EMAIL PROTECTED] -- http://www.iki.fi/simo/ === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Expanding a Raid5 filesystem
At 06:52 PM 12/15/1999 +, Jim Ford wrote: >I was so pleased at the performance of my raid5 setup that I decided to >try adding another disk. I altered the raidtab to show the new partition >(not as a spare) and rebooted. The new partition was detected OK but was >added to md0 as a spare, which was not as I hoped for. I had hoped that it >would just add to md0 according to the formula in the HOWTO (N-1)*S, thus >increasing the available disk space. /dev/mdstat showed that it was part >of md0, but the size of md0 hadn't changed. I also found that even if I >marked the new partition as a failed-disk in the raidtab, the system still >insisted on using it - it's only when I physically remove the disk that >the array is reconstructed. How do I add a new partition to an existing >raid5 array? > Jim, Not exactly sure, but try "raidhotadd" and see what happens. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Abandoned root Raid0 - success with root Raid5!
Jim, If you have the PCI space and the cards, maybe re-construct the whole thing with each drive on a seperate controller... That will give you faster access, as each controller can allocate it's 20mb/sec to each drive. At 07:41 PM 12/12/1999 +, Jim Ford wrote: > >It's all worked so well that I'm resetting it all up with swap on a raid5 >partition (thanks - Bruno Prior!) and a spare disk. I'm also worried about >the performance of the ISA AHA1542 controller, so I'm going to rob another >of my machines of its PCI NCR53C810 and use that instead. (I've also >considered fitting an AHA1540 I have in addition to the AHA1542 and >splitting the disks between them - I'm not sure what's best. Comments >welcomed!) > >I hope the forgoing - whilst repeating much of what's in Jakob >Oestergard's HOWTO, is helpfull! > >Regards: Jim Ford > === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: RAIDtools for kernel 2.3.29
It sounds like 2.3.29 forgot the raidtools patch to be included.
try patching it and enter N to any errors then try again.
At 09:19 PM 12/12/1999 +1100, Andre Pang wrote:
>Hi,
>
> I've been succesfully using raidtools-0.90 (from
>ftp.kernel.org:/pub/linux/daemons/raid/alpha) for the 2.2.x kernel range but
>I've been unable to get them to work with 2.3.29.
>
> Is there a more recent of the raidtools I should be using, and if so,
>where do I get them from? I've searched the linux-raid mailing list
>archives for the last month or two but haven't been able to find an answer.
>
> Extra info if needed: /dev/md* is a block file (9,x), using a vanilla
>2.3.29 kernel, tried building RAID stuff both as modules and non-modules,
>and the last few lines of an strace mkraid /dev/md0 are:
>
>open("/dev/md0", O_RDONLY) = 4
>ioctl(4, 0x40480923, 0x804ffe0) = -1 EINVAL (Invalid argument)
>write(2, 0xbfffd0e8, 70mkraid: aborted, see the syslog and /proc/mdstat
>for potential clues.
>)= 70
>
> If it makes any difference, I'm using hde to hdh for my RAID devices.
>
> Thanks in advance,
>
>
>--
>: Andre Pang <[EMAIL PROTECTED]> - Purruna Pty Ltd - ph# 0411.882299 :
>: #ozone - http://www.vjolnir.org/ozone/:
===
David Cooley N5XMT Internet: [EMAIL PROTECTED]
Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068
We are Borg... Prepare to be assimilated!
===
Re: RAID 1 errors? Now What?
At 11:18 AM 12/9/1999 -0500, you wrote: >== >Now what? Does this mean that the disk is bad? I have other RAID 1's >living on the same two disks and they have not slipped into degraded >mode. Should i just try to raidhotadd the device back into the the RAID >and see if it corrects itself? >Thanks for any help. It could be a drive problem, but it could also be that since data is spread across the drives of an array, with only 2 drives, removing one removed half the data. Without at least 3 drives making up the array, it has nothing to reconstruct the data from when 1 drive goes bad. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: CDrom
Yeah but it would be hard to use a cd as raid... seeing how raid wants to write to the disks as it creates the MD device At 06:43 PM 12/1/1999 -0800, you wrote: >On Thu, 2 Dec 1999, [iso-8859-1] Jakob Østergaard wrote: > > > I can't think of a good reason to use CDs for permanent storage anymore. > > Back in the days where 600Megs was a lot, sure, the hottest thing was a > > CD tower. But today with 27G disks flying around at the same cost as my > > (now fairly old) dual-spin CD drive, it really is cheaper, faster and > > easier to just copy the CD contents to the harddrive. > > > >Using CD-R discs, in CD-ROM drives, to store system binaries and libraries >and tripwire databases is fairly useful if you can't afford to mark an >entire drive as read-only using jumpers. > >+++ath >Derek Vadala, [EMAIL PROTECTED], http://www.cynicism.com/~derek === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
RE: Performance .... MegaRAID
At 01:35 PM 11/15/1999 +, Matthew Clark wrote: >I'm going to try adding memory & a processor.. when we use Bonnie, the CPU >usage sometimes hits 97%.. this can't be good! I've found Bonnie to be really misleading... CPU useage is higher when setting it to run a single test file... Running it with 6 volumes, CPU useage drops to 19-21%... Opposite what would be expected. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
RE: Please Help - SCSI RAID device very slow
At 05:39 PM 10/27/1999 +0100, Matthew Clark wrote: >Does anyone know how I stop the MegaRAID using the onboard INTEL SCSI >Controller? (i960) It should be using my SYMBIOS card...??? It will only use the card it is physically connected to. Move the cable to the SYMBIOS card and it will be seen there. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Recovering from a lost disk
At 05:59 PM 10/25/1999 +, Marc Haber wrote: >On Mon, 25 Oct 1999 12:20:57 -0200, you wrote: > >Marc Haber wrote: > >> These tools don't seem to be included with the raidtools snapshots. > >> Where do I get them from? > > > >They are symbolic links of raidstart (they wouldn't be in the raidtools > >source directory after a 'make', but 'make install' should create them > >in /sbin) > >I see. Naturally, I didn't see them because this is a test system and >I never bothered to make install. The total absence of any docs >(neither raidhotadd, raidsetfaulty nor raidhotremove to have man >pages) didn't make finding my mistake any easier. > >Is --help really the only documentation besides the >source code? Nope.. When you do make install it adds man pages. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Help needed w/ HP SureStore DAT24
At 12:33 PM 10/21/1999 -0500, Stephen Waters wrote: >i've found that software compression (with our cheesy seagate backup >exec s/w anyway..) compresses better than hardware because it is able to >reorganize the data in a more compressible manner rather than the drive >just compressing whatever hits the buffer. >we average just under 18GB per tape w/ full compression, although i have >seen instances where it would hit 20GB. it's extremely data dependant i >would expect. I have an Exabyte 8505XL on an adaptec 2940UW. It is set to hardware compression, but if the SW compression is better, do I just need to turn HW compression on the drive off to use SW compression? Thanks, Dave ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: raidtools kernel patch
Thomas Waldmann wrote: > > Am Sun, 17 Oct 1999 schrieb Robert: > > > Hm, those 2.2.11 raid patches did not work for me. After applying and > > ignoring the 2 errors, I got this upon compiling: > > I applied the raidpatch 2.2.11/0824 to a 2.2.12 kernel and it worked well. > There were only some hunks (all in same file) rejected - but the changes they > would have made were already present in the original kernel, so no real problem. > > > This was a stock 2.2.12 kernal from the tar-ball, with only one other > > patch applied first: ide.2.2.12.19991014.patch > > Maybe first do the raid-patch then the other patch !? > > And: do not ignore messages patch gives you, but see what it exactly did and > what not. > The reason the 2.2.11 patch fails a hunk is because that part of the code is applied already in the 2.2.12 code.
Re: Re: raid problem
Also running RAID5 with 12 4.2G 1RPM Seagate Cheetah drives in a SUN D1000 drive array. At 09:15 AM 10/15/1999 -0400, David Cooley wrote: >At 10:33 AM 10/15/1999 +0200, Mathieu Arnold wrote: > >>well, i'm using a bi celeron motherboard (abit bp6) and smp is really >>better with 2.3 kernels > >I'm curious what you mean by "working better". I'm running kernel 2.2.12 >on a Sun Ultra 2 with Dual 300MHz Ultra CPU's and have had no problems... >It screams! >======= >David Cooley N5XMT Internet: [EMAIL PROTECTED] >Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 >We are Borg... Prepare to be assimilated! >=== > === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Re: raid problem
At 10:33 AM 10/15/1999 +0200, Mathieu Arnold wrote: >well, i'm using a bi celeron motherboard (abit bp6) and smp is really >better with 2.3 kernels I'm curious what you mean by "working better". I'm running kernel 2.2.12 on a Sun Ultra 2 with Dual 300MHz Ultra CPU's and have had no problems... It screams! ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re:
At 01:47 PM 10/13/1999 +0200, Alvarez Angel Javier wrote: >is there a patch for autodetec raid for the 2.3.19+? The 2.3.x kernels are development... IE: works in progress. They may or may not have the latest of each driver/tool, but the patches also may not be available. 2.2.12 is fully functional and fully supported. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: where is autodetect raid code in 2.3.19??
I do not think the raid patches are included in the 2.3.X kernels yet. At 08:48 PM 10/11/1999 +0200, Alvarez Angel Javier wrote: >Hi All!! > >I`ve Mandrake 6.0 running with autodetect Raid working really well, but i >have to install an ATM adapter , so and i´m trying Kernel 2.3.19, but now >Autodetec RAID is missing in the kernel configuration and it doesn´t boot at >all from my md devices!! > >I`ve change /drivers/block/Config.in to offer autodetect features in the >'make menuconfig screen' but not success. >The autodetect raid parttions code seems to be missing? > >I scanned the list but i didnt found any clues about this... :-( > >does anyone know anything about this problem with 2.3.19? > >Thanks in advance... > >--- >Angel J. Alvarez Miguel <[EMAIL PROTECTED]> >Servicios Informaticos. Area de Sistemas 91 - 885 47 04 >Universidad de Alcala >---- >--- === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: raid 1 problem with kernel 2.2.12
You need the kernel raid patch At 06:57 PM 10/9/1999 +0200, Eugenia Franzoni wrote: >Hi :-) > >I'm installing a RAID-1 system with RedHat 6.0. I upgraded the kernel to >the stock 2.2.12 from kernel.org, but this is the error I have: > >[root@linux /etc]# mkraid --configfile /etc/raid1.conf /dev/md0 >handling MD device /dev/md0 >analyzing super-block >disk 0: /dev/hda3, 6257317kB, raid superblock at 6257216kB >disk 1: /dev/hdc3, 6254010kB, raid superblock at 6253888kB >mkraid: aborted, see the syslog and /proc/mdstat for potential clues. > >In the syslog there is nothing, and /proc/mdstat gives: > >[root@linux /etc]# cat /proc/mdstat >Personalities : [3 raid1] >read_ahead not set >md0 : inactive >md1 : inactive >md2 : inactive >md3 : inactive > >I have of course compiled raid 1 in the kernel (not as module) and >installed raidtools (ver 0.90-5 of the rpm package). > >Any suggestion? :-) > >Thanks > >Eugenia === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
FDISK
Where can the new version of FDISK be found at? === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Rh 6.0 autodetecting kernel
At 07:38 AM 10/6/1999 -0400, you wrote: >I am using RH 6.0 and the kernel is 2.2. I am using raid .90-3, (a rpm >package) and I have looked over every doc I could find on raid. A few >newsgroups have references to the md-personality-3 problem but none have >any solutions. > >If the kernel weren't compiled for raid why would it be complaining >about md-personality-3? Could it be that when I installed raid .90-3 >that it applied a module to be installed at boot time but the kernel >isn't prepared to deal with it? I thought that what the modules were >for, so you could add functionality to the kernel as it is needed. The raid error you saw, combined with the alias you assigned means raid support is modular on your system, not compiled into your kernel... >If the kernel doesn't have some required piece of raid installed, how >can I tell? Is there some query I can do to the kernel to find out? My >time is limited and I don't want to go through the trouble of setting up >to compile the kernel if I don't have to. Look at your messages file (/var/log/messages). As it loads the kernel and it's spewing messages, you should see "raid personality x registered". If you don't see it, then it's in a module and you need to do an mkinitrd to enable the raid modules at boot time. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Optimal Cluster/stride
At 03:41 PM 9/30/1999 -0400, James Manning wrote: >[ Thursday, September 30, 1999 ] Tom Livingston wrote: > > my tests seemed to indicate the same thing... 4k chunk was faster than > 128k > > > > I understand that this doesn't necessarily fit in with the theory of these > > things. > >I'm not so sure it doesn't, as when it comes down to it you need to keep >as many drives actively fetching data as possible (hence adjustable raid1 >read-balance testing still on my to-do list), and with huge chunk sizes >you'll end up in large periods of time where you're only dealing with one >(or a small number of) drives. > >All my (frequently scientific :) testing has shown quite the sweet spot >at 4k, even with my datafiles (none smaller than 1GB) Can you edit raidtab and change the chunk size without corrupting existing data? === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Optimal Cluster/stride
At 11:11 AM 9/30/1999 -0500, [EMAIL PROTECTED] wrote: >Greetings.. I really appreciate the help yesterday on getting my RAID working >on my UltraII. (Kudos n5xmt!) > >The last question I have is how do I figure out the optimal cluster size/block >size/stride for my RAID. I will have 2 configured RAID-5 partitions: > >16 - 4.1Gig Drives (/dev/md0) >26 - 4.1Gig Drives (/dev/md1) > >The first will be a drive for innd, so figure lots of small files. The second >will be an anonymous FTP server for some mirrors we will be running. Figure >larger files on the second. If you need anything more, please let me know. If you'll have lots of small files, try a chunk size of 4K... should keep waste to a minimum. On the other for the mirror FTP, 16 is probably a good compromise. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
RE: putting failed disk back in array
At 12:43 PM 9/30/1999 +0300, [EMAIL PROTECTED] wrote: >Hi! > >Try using raidhotadd. My idea is that it should do the trick. Just had to do this this morning... After 4 days of solid crunching with 2 processes of Seti@home running and 2 processes of Bonnie, 10 volumes each running in a loop, drive 5 of 6 on my /dev/md0 was flagged as being stale... Unmounted /dev/md0, did raidhotadd /dev/md0 /dev/sdf and it added it, I remounted it while it was still resyncing /dev/sdf, when it was finished, I checked all the data and it was in tact and fine! ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Boot Linear/RAID-1 [was: Root Raid Questions....]
At 12:00 PM 9/27/1999 -0400, Stanley, Jeremy wrote: >If we don't already have a HOWTO section on this issue, we probably >should add one. We've seen more and more questions on this topic of >late... Just my half-nybble. > >On a similar note, wouldn't it be possible to boot from RAID-1/5 using a >similar method if the chunk size was greater than the kernel size? >Obviously this would be a big chunk size, and only particularly useful >for systems serving big files. It sounds feasable, but you'd lose the benefits of raid if one file was in one chunk... that drive goes and any files smaller than one chunk on that drive are history ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Linux LVM & Software RAID.
At 04:29 PM 9/24/1999 +0200, Andreas Kostyrka wrote: >Hi! > >Just been wondering if somebody does have a working 2.2.12 system that >does include these features: >-) LVM 0.7 >-) md-raid0145 > >Actually, I've tried to do this, but there is a small conflict in >ll_rw_blk.c. Obviously I didn't solve it correctly, because after mkraid >on /dev/md0 (RAID5 on 5 SCSI discs), my mke2fs crashed. > >So did anybody solve this conflict, or am I on my own? I don't have LVM, but am running the 2.2.12 kernel with the o824 raid patch installed against it, and have 2 MD devices configured from 12 SCSI disks on a Sun Ultra 2. It's rock stable. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Hot swap problems... continued
At 05:02 PM 9/24/1999 +0200, you wrote: >Mika Kuoppala wrote: > > > raidsetfaulty /dev/md0 /dev/sda1 > >Shouldn't there be a > raidhotremove /dev/md0 /dev/sda1 >before low level removal of the scsi device? >Could explain sudden panics, if an unexpected state occurs. That would make sense ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Linux box locking up ..
At 02:59 PM 9/23/1999 +0200, HA Quoc Viet wrote: >Well, I jumped from 2.2.10+SMP to 2.2.12+SMP. I've never used RAID >and never got a lock/oops ... I went from 2.2.5 smp to 2.2.11 smp to 2.2.12 smp, all with raid. I had a few probs with raid until I added the raid patch, but the machine is rock stable... Sun Ultra Enterprise 2, dual 300MHz CPU's and an External SUN StorEdge D1000 raid. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
RE: Raidtools
At 09:52 AM 9/23/1999 -0400, Drenning Bruce wrote: >not to quibble, but the latest version is 0.90-5 (on i386 anyway). Ah.. I need to get it then... Last time I grabbed them is was still -3... I need to check more often! === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Raidtools
At 02:30 PM 9/23/1999 +0200, Kay Salzwedel wrote: >Hi folks, > >thanks for the replays to my earlier problem. Now I got kernel 2.2.11 >and the patch raid0145-19990824-2.2.11. It went well until I tried to >compile the latest raidtools (raidtools-0.41). During the configure it >say's that I have no Raid definitions in the kernel headers: Raidtools 0.41 isn't the latest and doesn't work with the patch... Raidtools 0.90-3 is the latest and works great with the patch ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: RAID is now working...
At 11:02 PM 9/19/1999 +0200, Florian Lohoff wrote: >As i understand Dave and the Source on every initializing of the Cards >the firmware gets loaded into the chips ... So you will always >end up with the firmware in the driver ... Yep... Looking at the code in qlogicpti.c that's what it does... The firmware is in qlogicpti_asm.c >Flo >PS: I have got problems with the QlogicPTI SBUS too. I have problems > under high raid load where the SCSI bus seems to freeze (The drivers > does ongoing resets of the single targets which does not stop until > i switch the machine off) Mine started doing that on the second PTI card I installed... Got looking at the boot messages where it first detects the cards... My old one (working fine) is detected as ultra scsi... the "new one" is detected as fast scsi... Both cards have the same SUN part number on them, but the "new" one has ver 1.71 on the sticker on the prom on the board, and the "old" one (the one that works all the time) has 1.73 on it. The code read by the kernel driver in the boards is 1.21 for the one that fails and 1.25 on the good one. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
RE: Raid Questions
At 04:43 PM 9/17/1999 +0100, you wrote: > > I'm confused. You're using 2 devices of apparently equal size (which I > assume > > means they're the same kind of device). However, you have one defined > as an > > IDE disk and one defined as a SCSI disk in your raidtab file. Could > > that be the > > problem? > >You can mix SCSI and IDE in a software-RAID. It is more likely to be that in >upgrading to 2.2.12, Kenny didn't realize that he had to patch the kernel with >the raid0145 patch (from >ftp://ftp..kernel.org/pub/linux/daemons/raid/alpha), because the >stock RedHat 2.2.5 kernels came ready-patched. Will the 2.2.11 patch work on the 2.2.12 kernel? latest patch seems to be 2.2.11 === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Problem with mkraid for /dev/md0
At 09:51 AM 9/17/1999 -0400, Daniel Bidwell wrote: > > I have found that you need to re-partition the disks so you only have > > partition 1 and 3... > > 3 is whole disk, 1 is type FD and starts at cyl 1, not 0 > > Raidtools doesn't like any other partitions. > >I don't think that this is correct. I am running 2.2.12 with the 0.90 >raid tools and I have a set of 5 18G disks with 7 partitions on each >disk and 7 different RAID5 spread across the disk set. They are all >configured and running just fine. I was running Kernel 2.2.5-22 from RH 6 on Sparc. Regardless what partitoon I specified (/dev/sdc7 was what I tried first... plus partition 7 on the next 5 disks) it said /dev/sdc1 not found, mkraid aborting. Made a small partition 1 and tried again, still didn't like it. Went to the final configuration (next to final) with partitions 1 and 3, set up ok, but on next boot, it said the superblocks were corrupt... One of the readme's or how to's said cyl 0 is where it put those, so I changed partition 1 to start at cyl1 and all has been well. Some weirdness I am having now though is I installed a second SCSI controller... I broke up my 2 md devices so now each ones drives are on a seperate controller (6 on SCSI1, 6 on SCSI2). It won't use both SCSI controllers for md devices... It will start and mount the raid for the drives on SCSI 1, but fails for SCSI2... if I put all 12 drives back on one controller (either one... tested to ensure controller was good!) it will make both. The Kernel see's all 12 regardless of config, and /proc/partition has all 12 listed. It just won't use them. I upgraded to kernel 2.2.11, applied the raid patch and compiled/installed the latest raidtools for it... same result. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Trying raid1 with Mandrake Linux 6.0
When you partition the disk, start partition 1 at cylinder 1, not cyl 0. Also set the partition type to FD... From the message, it looks like /dev/hda2 is in use by linux elsewhere... try a df -k and see what it says about /dev/hda2 At 03:58 PM 9/17/1999 +0800, you wrote: >Hi ! > >My kernel is 2.2.9-19mdk with initrd-2.2.9-19mdkraid.img and >raidtools-0.90-5mdk. > >Whe I did mkraid /dev/md0, I got the following messages: > > handling MD device /dev/md0 > analyzing super-block > disk 0: /dev/hda2, 205632kB, raid superblock at 205568kB > /dev/hda2 is mounted > mkraid: aborted > >My /etc/raidtab as follow: > > raiddev /dev/md0 > raid-level1 > persistent-superblock 1 > nr-raid-disks 2 > chunk-size4 > device/dev/hda2 > raid-disk 0 > device/dev/hdc2 > raid-disk 1 > >cat /proc/mdstat gave the following result: > > Personalities : [3 raid1] > read_ahead not set > md0 : inactive > md1 : inactive > md2 : inactive > md3 : inactive > >What else did I missed ? > >Please help ! > >Thank you. === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: Problem with mkraid for /dev/md0
At 12:57 PM 9/17/1999 +0200, you wrote: >Hello, > >we are trying to set up RAID1 as described in the Software-RAID-howto. > >md-support is compiled into the kernel (not as module) and RAID1 too. >Raid0 ist not compiled in, because the Kernel appears to support Raid0 >for swap by default (correct me, when I'm wrong). Swap is setup as RAID0 >and seems to work fine. > >[RAID1] >There are two partition equally sized on two different HDs: >sdb6 and sdc6 both with no filesystem on them. I have found that you need to re-partition the disks so you only have partition 1 and 3... 3 is whole disk, 1 is type FD and starts at cyl 1, not 0 Raidtools doesn't like any other partitions. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: superblock Q/clarification
At 04:29 PM 11/4/1999 +0100, [EMAIL PROTECTED] wrote: >[ Thursday, November 4, 1999 ] David Cooley wrote: > >> Does this mean we no longer have to start raid partitions at block 1 > >> instead of block zero? > >Just out of curiosity, when was this the case? I've done s/w raid's >on drives (not making partitions, so I lost autorun unfortunately) >and never had a problem... It's probably something to do with the fact that I'm on a Sparc Ultra 2 machine running Linux. Didn't think Linux saw the drives differently between platforms, but I guess it does. ======= David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
Re: superblock Q/clarification
When I first set up my Raid 5, I made the partitions with Fdisk, and
started /dev/hdc1 at block 0, the end was the end of the disk (single
partition per drive except /dev/hdc5 is type whole disk).
It ran fine until I rebooted, when it came up and said there was no valid
superblock. I re-fdisked the drives and re-ran mkraid and all was well
until I rebooted. I read somewhere (can't remember where though) that
block 0 had to be isolated as the superblock was written there... I
re-fdisked all my drives so partition /dev/hdx1 started at block 1 instead
of zero and haven't had a problem since.
I'm running Kernel 2.2.12 with raidtools 0.90 and all the patches..
At 04:17 PM 11/4/1999 +0100, Jakob Østergaard wrote:
>On Thu, Nov 04, 1999 at 10:01:41AM -0500, David Cooley wrote:
>...
> >
> > Does this mean we no longer have to start raid partitions at block 1
> > instead of block zero?
>
>I'm sorry, but I have no idea of what you're referring to...
>
>When accessing the RAID device you can't see that there is a superblock
>at all. You can't access the superblock via valid accesses to the MD
>device.
>
>I might be misunderstanding your question... When did you ever have to
>start anything at block 1 instead of block 0 ?
>
>(Gee, I hope this isn't in the HOWTO as well ;)
>
>--
>
>: [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}...:
===
David Cooley N5XMT Internet: [EMAIL PROTECTED]
Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068
We are Borg... Prepare to be assimilated!
===
Re: superblock Q/clarification
At 03:17 PM 11/4/1999 +0100, Jakob Østergaard wrote: >On Thu, Nov 04, 1999 at 08:09:31AM -0500, James Manning wrote: > > My impression was that the s/w raid code only wrote to the ends (last 4k) > > of each device, so I'm trying to clarify the following paragraph from > > > > > http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/Software-RAID.HOWTO-4.html#ss4.7 > > > > The persistent superblocks solve these problems. When an > > array is initialized with the persistent-superblock option in > > the /etc/raidtab file, a special superblock is written in the > > *beginning* of all disks participating in the array. This allows the > >It's a bug ! > >The superblocks are written in the end of all disks. I'll fix this in >the HOWTO ASAP. Does this mean we no longer have to start raid partitions at block 1 instead of block zero? === David Cooley N5XMT Internet: [EMAIL PROTECTED] Packet: N5XMT@KQ4LO.#INT.NC.USA.NA T.A.P.R. Member #7068 We are Borg... Prepare to be assimilated! ===
