Ohh yuck! My RAID doesn't start...

2000-03-17 Thread Eric Y. Theriault

Hello--



I was wondering if perhaps someone could help me.  In a rush, I turned off my machine 
a few seconds before it was done, and now my SYSLOG states:

===
Mar  9 18:47:07 ingress kernel: (read) sda1's sb offset: 4441856 [events: 0033] 
Mar  9 18:47:07 ingress kernel: (read) sdb1's sb offset: 4441856 [events: 0032] 
Mar  9 18:47:07 ingress kernel: (read) sdc1's sb offset: 4441856 [events: 0032] 
Mar  9 18:47:07 ingress kernel: (read) sdd1's sb offset: 4441856 [events: 0031] 
Mar  9 18:47:07 ingress kernel: autorun ... 
Mar  9 18:47:07 ingress kernel: considering sdd1 ... 
Mar  9 18:47:07 ingress kernel:   adding sdd1 ... 
Mar  9 18:47:07 ingress kernel:   adding sdc1 ... 
Mar  9 18:47:07 ingress kernel:   adding sdb1 ... 
Mar  9 18:47:07 ingress kernel:   adding sda1 ... 
Mar  9 18:47:07 ingress kernel: created md0 
Mar  9 18:47:07 ingress kernel: bindsda1,1 
Mar  9 18:47:07 ingress kernel: bindsdb1,2 
Mar  9 18:47:07 ingress kernel: bindsdc1,3 
Mar  9 18:47:07 ingress kernel: bindsdd1,4 
Mar  9 18:47:07 ingress kernel: running: sdd1sdc1sdb1sda1 
Mar  9 18:47:07 ingress kernel: now! 
Mar  9 18:47:07 ingress kernel: sdd1's event counter: 0031 
Mar  9 18:47:07 ingress kernel: sdc1's event counter: 0032 
Mar  9 18:47:07 ingress kernel: sdb1's event counter: 0032 
Mar  9 18:47:07 ingress kernel: sda1's event counter: 0033 
Mar  9 18:47:07 ingress kernel: md: superblock update time inconsistency -- using the 
most recent one 
Mar  9 18:47:07 ingress kernel: freshest: sda1 
Mar  9 18:47:07 ingress kernel: md: kicking non-fresh sdd1 from array! 
Mar  9 18:47:07 ingress kernel: unbindsdd1,3 
Mar  9 18:47:07 ingress kernel: export_rdev(sdd1) 
Mar  9 18:47:07 ingress kernel: md0: kicking faulty sdc1! 
Mar  9 18:47:07 ingress kernel: unbindsdc1,2 
Mar  9 18:47:08 ingress kernel: export_rdev(sdc1) 
Mar  9 18:47:08 ingress kernel: md0: removing former faulty sdd1! 
Mar  9 18:47:08 ingress kernel: md: md0: raid array is not clean -- starting 
background reconstruction 
Mar  9 18:47:08 ingress kernel: raid5 personality registered 
Mar  9 18:47:08 ingress kernel: md0: max total readahead window set to 6144k 
Mar  9 18:47:08 ingress kernel: md0: 3 data-disks, max readahead per data-disk: 2048k 
Mar  9 18:47:08 ingress kernel: raid5: device sdb1 operational as raid disk 1 
Mar  9 18:47:08 ingress kernel: raid5: device sda1 operational as raid disk 0 
Mar  9 18:47:08 ingress kernel: raid5: not enough operational devices for md0 (2/4 
failed) 
Mar  9 18:47:08 ingress kernel: RAID5 conf printout: 
Mar  9 18:47:08 ingress kernel:  --- rd:4 wd:2 fd:2 
Mar  9 18:47:08 ingress kernel:  disk 0, s:0, o:1, n:0 rd:0 us:1 dev:sda1 
Mar  9 18:47:08 ingress kernel:  disk 1, s:0, o:1, n:1 rd:1 us:1 dev:sdb1 
Mar  9 18:47:08 ingress kernel:  disk 2, s:0, o:0, n:2 rd:2 us:1 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel:  disk 3, s:0, o:0, n:3 rd:3 us:1 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel:  disk 4, s:0, o:0, n:0 rd:0 us:0 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel:  disk 5, s:0, o:0, n:0 rd:0 us:0 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel:  disk 6, s:0, o:0, n:0 rd:0 us:0 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel:  disk 7, s:0, o:0, n:0 rd:0 us:0 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel:  disk 8, s:0, o:0, n:0 rd:0 us:0 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel:  disk 9, s:0, o:0, n:0 rd:0 us:0 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel:  disk 10, s:0, o:0, n:0 rd:0 us:0 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel:  disk 11, s:0, o:0, n:0 rd:0 us:0 dev:[dev 00:00] 
Mar  9 18:47:08 ingress kernel: raid5: failed to run raid set md0 
Mar  9 18:47:08 ingress kernel: pers-run() failed ... 
Mar  9 18:47:08 ingress kernel: do_md_run() returned -22 
Mar  9 18:47:08 ingress kernel: unbindsdb1,1 
Mar  9 18:47:08 ingress kernel: export_rdev(sdb1) 
Mar  9 18:47:08 ingress kernel: unbindsda1,0 
Mar  9 18:47:08 ingress kernel: export_rdev(sda1) 
Mar  9 18:47:08 ingress kernel: md0 stopped. 
Mar  9 18:47:08 ingress kernel: ... autorun DONE. 
Mar  9 18:47:08 ingress kernel: Bad md_map in ll_rw_block 
Mar  9 18:47:08 ingress kernel: EXT2-fs: unable to read superblock
===

I'm running 0.90 under RedHat 6.0, using 4 4GB drives using RAID5.  Is there a way to 
force it to work?  I need to get to the data on these drives.  Thanks for any 
assistance in this matter.

--
Eric Y. Theriault



Problems with IDE RAID5

2000-03-17 Thread root

Having some problems setting up IDE RAID5 on Kernel 2.2.14

Kernel: 2.2.14

Patches:
ide_2_2_14_2124_patch.gz
raid-2_2.14-B1  (Encountered Hunk problems, but I've heard this is
normal)

Tools:
raidtools-19990824-0_90_tar.gz

I have three Segate 6GB ATA66 Harddrives, two of which are hanging
off of a Promise 66 card and the third is sitting off of the second IDE
controller on the mother board.

My problem is this:
-
 mkraid --**-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/hdc1, 6244528kB, raid superblock at 6244416kB
disk 1: /dev/hde1, 6250198kB, raid superblock at 6250112kB
disk 2: /dev/hdg1, 6250198kB, raid superblock at 6250112kB
mkraid: aborted, see the syslog and /proc/mdstat for potential clues.
-

syslog reports no errors and my /proc/mdstat just reports:

Personalities : [4 raid5]
read_ahead not set
md0 : inactive
md1 : inactive
md2 : inactive
md3 : inactive

I'm not sure where to go from here.  Anyone have any ideas?  I'll
list some additional information below.  Oh yeah, I have no problems
talking to the drives themselves.  I setup a filesystem on each one
and mounted it just to see if they worked without a problem.

Here is my /etc/raidtab file:

raiddev   /dev/md0
raid-level  5
nr-raid-disks  3
persistent-superblock   1
chunk-size  128
parity-algorithm left-symmetric
device   /dev/hdc1
raid-disk  0
device   /dev/hde1
raid-disk  1
device   /dev/hdg1
raid-disk  2

Here is some information from dmesg:

PIIX3: IDE controller on PCI bus 00 dev 39
PIIX3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xff90-0xff97, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xff98-0xff9f, BIOS settings: hdc:pio, hdd:pio
PDC20262: IDE controller on PCI bus 00 dev 58
PDC20262: not 100% native mode: will probe irqs later
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0xff00-0xff07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xff08-0xff0f, BIOS settings: hdg:pio, hdh:pio
hda: WDC AC33100H, ATA DISK drive
hdb: FX120T, ATAPI CDROM drive
hdc: ST36422A, ATA DISK drive
hde: ST36422A, ATA DISK drive
hdg: ST36422A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xfff0-0xfff7,0xffe6 on irq 11
ide3 at 0xffa8-0xffaf,0xffe2 on irq 11
hda: Disabling (U)DMA for WDC AC33100H
hda: DMA disabled
hda: WDC AC33100H, 3020MB w/128kB Cache, CHS=767/128/63
hdc: ST36422A, 6103MB w/256kB Cache, CHS=13228/15/63, (U)DMA
hde: ST36422A, 6103MB w/256kB Cache, CHS=13228/15/63, UDMA(33)
hdg: ST36422A, 6103MB w/256kB Cache, CHS=13228/15/63, UDMA(33)
Partition check:
 hda: hda1 hda2  hda5 hda6 hda7 
 hdc: [PTBL] [826/240/63] hdc1
 hde: hde1
 hdg: hdg1













Re: Getting around disk numbering bullwinkle

2000-03-17 Thread David S. Miller

   From: Gregory Leblanc [EMAIL PROTECTED]
   Date:   Wed, 15 Mar 2000 20:21:04 -0800

   P.S. What's up with vger?  Is it dying?  Do they need a nice SS2 to replace
   it or something?

It's already an SS10 :-)

It is being replaced, sit tight.

Later,
David S. Miller
[EMAIL PROTECTED]



No Subject

2000-03-17 Thread liuxg

Hello all£¬

 I havemade some changes  in linux raid , and re-compiled
it  . When I run  mkraid /dev/md0 ,everything is ok! But when I
run  mount /dev/md0 /mnt ,something is wrong:
  It say  "Got md request
   not good."
  Can some body tell me Why it caused the error ?
 


Thanks in advance!

liuxg
[EMAIL PROTECTED]
 Liuxg 
 Department  of CS
 Nankai Universit



Re: Root on RAID1

2000-03-17 Thread phil

On Wed, Mar 15, 2000 at 08:24:54PM +0100, Luigi Gangitano wrote:
 Hi all,
 I need some help setting up boot on a RAID1 device. I used Method 2 of  
 Jakob OEstergaard's latest HowTo. I got it working, now my system mounts 
 /dev/md0 as root partition. But if I try to update LILO (to make it working on 
 the second hd's MBR) it says it can't do anything with device 0x900.
 
 I've already patched lilo-21 with lilo.raid patch.
 
 Any hint?

I've been using a boot-floppy with good success.  I just did a 'rdev
/dev/fd0 /dev/md0' and went on my way.  Since I don't reboot the box
more than, say, once a month, it really doesn't seem to matter that
the kernel is loaded from a floppy. (Make copies of that floppy! ;')
 
 Can you please tell me where can I find the latest raid-tools? I found raidtools-
 dangerous on http://people.redhat.com/mingo and didn't try to use it.

Good question.  From my impression, Linux (software) raid support got
a bit divided up, so who knows where the latest and most *stable*
version is?


Phil

-- 
Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR
   [EMAIL PROTECTED] -- http://www.netroedge.com/~phil
 PGP F16: 01 D2 FD 01 B5 46 F4 F0  3A 8B 9D 7E 14 7F FB 7A



RE: Problems with IDE RAID5

2000-03-17 Thread Gregory Leblanc

 -Original Message-
 From: root [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, March 15, 2000 2:11 PM
 To: [EMAIL PROTECTED]
 Subject: Problems with IDE RAID5
 
 
 Having some problems setting up IDE RAID5 on Kernel 2.2.14
 
 Kernel: 2.2.14
 
 Patches:
 ide_2_2_14_2124_patch.gz
 raid-2_2.14-B1  (Encountered Hunk problems, but I've heard this is
 normal)

What problems did you have?  That patch should apply cleanly, or, at least,
it has for me.  

[snip]
 
 PIIX3: IDE controller on PCI bus 00 dev 39
 PIIX3: not 100% native mode: will probe irqs later
 ide0: BM-DMA at 0xff90-0xff97, BIOS settings: hda:pio, hdb:pio
 ide1: BM-DMA at 0xff98-0xff9f, BIOS settings: hdc:pio, hdd:pio
 PDC20262: IDE controller on PCI bus 00 dev 58
 PDC20262: not 100% native mode: will probe irqs later
 PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary 
 PCI Mode.
 ide2: BM-DMA at 0xff00-0xff07, BIOS settings: hde:pio, hdf:pio
 ide3: BM-DMA at 0xff08-0xff0f, BIOS settings: hdg:pio, hdh:pio

I don't know what the second controler is, but you're getting all drives in
PIO mode.  :(  I have the same problem on my PIIX3 controllers when running
with the IDE patch, but I haven't had time to talk to the authors.  My
suspicion is that your kernel didn't get everything patched correctly.  If
you can send the output from that patch command, or try downloading it again
(note: download using lynx and 'print' to a file does NOT work).
Greg



RFC: RAID superblock layout fix and reserved-bytes support

2000-03-17 Thread Jakub Jelinek

Hi!

BEWARE: Don't use the following patch in production, it might eat your RAID
set for breakfest.

Attached is a patch which does 4 things:
- tries to solve cleanly the RAID superblock issues on non-x86 architectures
(where sizeof(md_super_t) was bigger than 4096, usually 4104) by introducing
RAID 0.91.x on-disk format which is binary compatible with the 0.90 for
i386 (and at the same time changes it from native-endian to little-endian).
- introduces reserved-bytes setting in raidtab, for which the default is
auto-probed by mkraid if not specified. If non-zero, the RAID array will
make sure first reserved_bytes on the disk are never touched (resynced or
whatever). This makes it possible e.g. to place RAID partition to cylinder 0
on a disk with Sun partition table.
- in raid1.c raid1_kmalloc allocated a wrong size
The patch is against 2.2.14 with 2.2.14-B1 RAID patch, because 2.3.99-pre2
is missing the raid1/5 bits. I can make try to port the remaining files
changes to 2.3.99-pre2 though.
- raidtab.5 man page fix

I'm looking for testers both on x86 and non-x86.

Cheers,
Jakub
___
Jakub Jelinek | [EMAIL PROTECTED] | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.99-pre2 on a sparc64 machine (1343.49 BogoMips)
___


--- linux/arch/sparc64/kernel/ioctl32.c.jj  Mon Jan 24 11:36:41 2000
+++ linux/arch/sparc64/kernel/ioctl32.c Fri Mar 10 17:32:37 2000
@@ -2022,12 +2022,14 @@ asmlinkage int sys32_ioctl(unsigned int 

/* 0x09 */
case /* RAID_VERSION */ _IOR (MD_MAJOR, 0x10, char[12]):
-   case /* GET_ARRAY_INFO */   _IOR (MD_MAJOR, 0x11, char[72]):
+   case /* GET_ARRAY_INFO */   _IOR (MD_MAJOR, 0x11, char[128]):
+   case /* OLD_GET_ARRAY_INFO */   _IOR (MD_MAJOR, 0x11, char[72]):
case /* GET_DISK_INFO */_IOR (MD_MAJOR, 0x12, char[20]):
case /* CLEAR_ARRAY */  _IO (MD_MAJOR, 0x20):
case /* ADD_NEW_DISK */ _IOW (MD_MAJOR, 0x21, char[20]):
case /* HOT_REMOVE_DISK */  _IO (MD_MAJOR, 0x22):
-   case /* SET_ARRAY_INFO */   _IOW (MD_MAJOR, 0x23, char[72]):
+   case /* SET_ARRAY_INFO */   _IOW (MD_MAJOR, 0x23, char[128]):
+   case /* OLD_SET_ARRAY_INFO */   _IOW (MD_MAJOR, 0x23, char[72]):
case /* SET_DISK_INFO */_IO (MD_MAJOR, 0x24):
case /* WRITE_RAID_INFO */  _IO (MD_MAJOR, 0x25):
case /* UNPROTECT_ARRAY */  _IO (MD_MAJOR, 0x26):
--- linux/drivers/block/md.c.jj Mon Jan 24 11:36:42 2000
+++ linux/drivers/block/md.cThu Mar 16 14:29:46 2000
@@ -11,6 +11,8 @@
- kerneld support by Boris Tobotras [EMAIL PROTECTED]
- kmod support by: Cyrus Durgin
- RAID0 bugfixes: Mark Anthony Lisher [EMAIL PROTECTED]
+   - superblock layout on non-x86 fixes and reserved_bytes support by
+ Jakub Jelinek [EMAIL PROTECTED]
 
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -299,9 +301,18 @@ static unsigned int calc_dev_sboffset (k
return size;
 }
 
+static inline unsigned int calc_dev_reserved (mddev_t *mddev)
+{
+   unsigned int reserved = mddev-sb-reserved_bytes;
+
+   reserved += mddev-sb-chunk_size - 1;
+   reserved = ~(mddev-sb-chunk_size - 1);
+   return reserved / 1024;
+}
+
 static unsigned int calc_dev_size (kdev_t dev, mddev_t *mddev, int persistent)
 {
-   unsigned int size;
+   unsigned int size, reserved;
 
size = calc_dev_sboffset(dev, mddev, persistent);
if (!mddev-sb) {
@@ -310,9 +321,25 @@ static unsigned int calc_dev_size (kdev_
}
if (mddev-sb-chunk_size)
size = ~(mddev-sb-chunk_size/1024 - 1);
+   reserved = calc_dev_reserved (mddev);
+   if (reserved  size)
+   size = 0;
+   else
+   size -= reserved;
return size;
 }
 
+__u64 __inline__ md_read_events (mdp_super_t *sb)
+{
+   return (((__u64)sb-eventshi)  32) | sb-eventslo;
+}
+
+void __inline__ md_write_events (__u64 events, mdp_super_t *sb)
+{
+   sb-eventshi = events  32;
+   sb-eventslo = events;
+}
+
 /*
  * We check wether all devices are numbered from 0 to nb_dev-1. The
  * order is guaranteed even after device name changes.
@@ -376,28 +403,13 @@ abort:
return 1;
 }
 
-static unsigned int zoned_raid_size (mddev_t *mddev)
+static inline unsigned int zoned_raid_size (mddev_t *mddev)
 {
-   unsigned int mask;
mdk_rdev_t * rdev;
struct md_list_head *tmp;
 
-   if (!mddev-sb) {
-   MD_BUG();
-   return -EINVAL;
-   }
-   /*
-* do size and offset calculations.
-*/
-   mask = ~(mddev-sb-chunk_size/1024 - 1);
-printk("mask %08x\n", mask);
-
ITERATE_RDEV(mddev,rdev,tmp) {
-printk(" rdev-size: %d\n", rdev-size);
-   

raid5 on 2.2.14

2000-03-17 Thread Seth Vidal

Hi folks,

got a small problem.
 I'm running redhat 6.1+ (2.2.14-5.0 kernels from rawhide and new
raidtools 0.90-6) I've checked and the 2.2.14-5.0 are using the B1 patch
from mingo's page. I think the raidtools they are using (mentioned above)
are the correct version.

Here is what happens:

I build a raid 5 array (5 disks) it builds and I can mount and write
things to it.

I'm not doing root fs on it but I build a new initrd anyway - it builds
and includes the raid5 modules - I rerun lilo.

I boot.

I get raidstart /dev/md0 
invalid argument /dev/md0

I've checked the archives and it looks like others have experienced this
problem but they've  all been related to other issues.

is there something i'm missing?
I think I've covered all the bases.

any ideas?

thanks
-sv