raid5 on 2.2.14
Hi folks, got a small problem. I'm running redhat 6.1+ (2.2.14-5.0 kernels from rawhide and new raidtools 0.90-6) I've checked and the 2.2.14-5.0 are using the B1 patch from mingo's page. I think the raidtools they are using (mentioned above) are the correct version. Here is what happens: I build a raid 5 array (5 disks) it builds and I can mount and write things to it. I'm not doing root fs on it but I build a new initrd anyway - it builds and includes the raid5 modules - I rerun lilo. I boot. I get raidstart /dev/md0 invalid argument /dev/md0 I've checked the archives and it looks like others have experienced this problem but they've all been related to other issues. is there something i'm missing? I think I've covered all the bases. any ideas? thanks -sv
RFC: RAID superblock layout fix and reserved-bytes support
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\
RE: Problems with IDE RAID5
> -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
Re: upgrade from 2.2.12-20 to 2.2.14 breaks stuff
On Wed, Mar 15, 2000 at 12:40:07PM -0800, Gregory Leblanc wrote: > The patch applied cleanly, and I compiled the kernel with all of the proper > options (AFAICT). When I try to boot with the new kernel, I get: > > md.c: sizeof(m_super_t) = 4096 > Autodetecting RAID Arrays > Autorun... > ...autorun done. > Bad md_map in ll_rw_block isofs_read_super: bread failed, dev=09:01, > iso_blknum=16, block=32 > kernel panic: VFS: unable to open root fs on 09:01 can you double-check that scsi, sd, your scsi adapter, raid1 are all built into the kernel, if they are modules you need to build an initrd. also check the partition type. L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l.
Re: Root on RAID1
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
No Subject
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: Getting around disk numbering bullwinkle
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]
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) 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
Ohh yuck! My RAID doesn't start...
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: bind Mar 9 18:47:07 ingress kernel: bind Mar 9 18:47:07 ingress kernel: bind Mar 9 18:47:07 ingress kernel: bind Mar 9 18:47:07 ingress kernel: running: 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: unbind 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: unbind 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: unbind Mar 9 18:47:08 ingress kernel: export_rdev(sdb1) Mar 9 18:47:08 ingress kernel: unbind 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