Re: is this raid5 OK ?
hi, 1) the kernel was: [EMAIL PROTECTED] ~]# uname -a Linux alfred 2.6.19-1.2288.fc5xen0 #1 SMP Sat Feb 10 16:57:02 EST 2007 i686 athlon i386 GNU/Linux now upgraded to: [EMAIL PROTECTED] ~]# uname -a Linux alfred 2.6.20-1.2307.fc5xen0 #1 SMP Sun Mar 18 21:59:42 EDT 2007 i686 athlon i386 GNU/Linux OS is fedora core 6 [EMAIL PROTECTED] ~]# mdadm --version mdadm - v2.3.1 - 6 February 2006 2) I got the impression that the old 350W power supply was to weak, I replaced it by a 400W version. 3) re-created the raid: [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hde1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdf1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdg1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdh1 [EMAIL PROTECTED] ~]# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 --spare-devices=0 /dev/hde1 /dev/hdf1 /dev/hdg1 /dev/hdh1 mdadm: layout defaults to left-symmetric mdadm: chunk size defaults to 64K mdadm: size set to 390708736K mdadm: array /dev/md0 started. [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdh1[4] hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] unused devices: none same as before. 4) did as dan suggested: [EMAIL PROTECTED] ~]# mdadm -S /dev/md0 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hde1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdf1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdg1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdh1 [EMAIL PROTECTED] ~]# mdadm --create /dev/md0 -n 4 -l 5 /dev/hd[efg]1 missing mdadm: array /dev/md0 started. [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] unused devices: none [EMAIL PROTECTED] ~]# mdadm --add /dev/md0 /dev/hdh1 mdadm: added /dev/hdh1 [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdh1[4] hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] [] recovery = 0.0% (47984/390708736) finish=406.9min speed=15994K/sec unused devices: none seems like it's working now - tnx ! cu - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this raid5 OK ?
Rainer Fuegenstein wrote: hi, 1) the kernel was: [EMAIL PROTECTED] ~]# uname -a Linux alfred 2.6.19-1.2288.fc5xen0 #1 SMP Sat Feb 10 16:57:02 EST 2007 i686 athlon i386 GNU/Linux now upgraded to: [EMAIL PROTECTED] ~]# uname -a Linux alfred 2.6.20-1.2307.fc5xen0 #1 SMP Sun Mar 18 21:59:42 EDT 2007 i686 athlon i386 GNU/Linux OS is fedora core 6 [EMAIL PROTECTED] ~]# mdadm --version mdadm - v2.3.1 - 6 February 2006 2) I got the impression that the old 350W power supply was to weak, I replaced it by a 400W version. 3) re-created the raid: [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hde1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdf1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdg1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdh1 [EMAIL PROTECTED] ~]# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 --spare-devices=0 /dev/hde1 /dev/hdf1 /dev/hdg1 /dev/hdh1 mdadm: layout defaults to left-symmetric mdadm: chunk size defaults to 64K mdadm: size set to 390708736K mdadm: array /dev/md0 started. [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdh1[4] hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] unused devices: none same as before. 4) did as dan suggested: [EMAIL PROTECTED] ~]# mdadm -S /dev/md0 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hde1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdf1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdg1 [EMAIL PROTECTED] ~]# mdadm --misc --zero-superblock /dev/hdh1 [EMAIL PROTECTED] ~]# mdadm --create /dev/md0 -n 4 -l 5 /dev/hd[efg]1 missing mdadm: array /dev/md0 started. [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] unused devices: none [EMAIL PROTECTED] ~]# mdadm --add /dev/md0 /dev/hdh1 mdadm: added /dev/hdh1 [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdh1[4] hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] [] recovery = 0.0% (47984/390708736) finish=406.9min speed=15994K/sec unused devices: none seems like it's working now - tnx ! This still looks odd, why should it behave like this. I have created a lot of arrays (when I was doing the RAID5 speed testing thread), and never had anything like this. I'd like to see dmesg to see if there was an error reported regarding this. I think there's more going on, the original post showed the array as up rather than some building status, also indicates some issue, perhaps. What is the partition type of each of these partitions? Perhaps there's a clue there. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this raid5 OK ?
Bill Davidsen wrote: This still looks odd, why should it behave like this. I have created a lot of arrays (when I was doing the RAID5 speed testing thread), and never had anything like this. I'd like to see dmesg to see if there was an error reported regarding this. I think there's more going on, the original post showed the array as up rather than some building status, also indicates some issue, perhaps. What is the partition type of each of these partitions? Perhaps there's a clue there. partition type is FD (linux raid autodetect) on all disks. here's some more info: the hardware is pretty old, an 800MHz ASUS board with AMD cpu and an extra onboard promise IDE controller with two channels. the server was working well with a 60 GB hda disk (system) and a single 400 GB disk (hde) for data. kernel was 2.6.19-1.2288.fc5xen0. when I added 3 more 400 GB disks (hdf to hdh) and created the raid5, the server crashed (rebooted, freezed, ...) as soon as there was more activity on the raid (kernel panics indicating trouble with interrupts, inpage errors etc.) I then upgraded to a 400W power supply, which didn't help. I went back to two single (non-raid) 400 GB disks - same problem. finally, I figured out that the non-xen kernel works without problems. I'm filling the raid5 since several hours now and the system is still stable. I haven't tried to re-create the raid5 using the non-xen kernel, it was created using the xen kernel. maybe xen could be the problem ? I was wrong in my last post - OS is actually fedora core 5 (sorry for the typo) current state of the raid5: [EMAIL PROTECTED] ~]# mdadm --detail --scan ARRAY /dev/md0 level=raid5 num-devices=4 spares=1 UUID=e96cd8fe:c56c3438:6d9b6c14:9f0eebda [EMAIL PROTECTED] ~]# mdadm --misc --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Fri Mar 30 15:55:42 2007 Raid Level : raid5 Array Size : 1172126208 (1117.83 GiB 1200.26 GB) Device Size : 390708736 (372.61 GiB 400.09 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Fri Mar 30 20:22:27 2007 State : active, degraded, recovering Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 64K Rebuild Status : 12% complete UUID : e96cd8fe:c56c3438:6d9b6c14:9f0eebda Events : 0.26067 Number Major Minor RaidDevice State 0 3310 active sync /dev/hde1 1 33 651 active sync /dev/hdf1 2 3412 active sync /dev/hdg1 4 34 653 spare rebuilding /dev/hdh1 here's the dmesg of the last reboot (when the raid was already created, but still syncing): Linux version 2.6.20-1.2307.fc5 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 Sun Mar 18 20:44:48 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009f000 end: 0009f000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009f000 size: 1000 end: 000a type: 2 copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 copy_e820_map() start: 0010 size: 1feec000 end: 1ffec000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 1ffec000 size: 3000 end: 1ffef000 type: 3 copy_e820_map() start: 1ffef000 size: 0001 end: 1000 type: 2 copy_e820_map() start: 1000 size: 1000 end: 2000 type: 4 copy_e820_map() start: size: 0001 end: 0001 type: 2 BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ffec000 (usable) BIOS-e820: 1ffec000 - 1ffef000 (ACPI data) BIOS-e820: 1ffef000 - 1000 (reserved) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. Using x86 segment limits to approximate NX protection Entering add_active_range(0, 0, 131052) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 131052 HighMem131052 - 131052 early_node_map[1] active PFN ranges 0:0 - 131052 On node 0 totalpages: 131052 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 991 pages used for memmap Normal zone: 125965 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI 2.3 present. Using APIC driver default ACPI: RSDP
Re: is this raid5 OK ?
On Fri, 30 Mar 2007, Rainer Fuegenstein wrote: Bill Davidsen wrote: This still looks odd, why should it behave like this. I have created a lot of arrays (when I was doing the RAID5 speed testing thread), and never had anything like this. I'd like to see dmesg to see if there was an error reported regarding this. I think there's more going on, the original post showed the array as up rather than some building status, also indicates some issue, perhaps. What is the partition type of each of these partitions? Perhaps there's a clue there. partition type is FD (linux raid autodetect) on all disks. here's some more info: the hardware is pretty old, an 800MHz ASUS board with AMD cpu and an extra onboard promise IDE controller with two channels. the server was working well with a 60 GB hda disk (system) and a single 400 GB disk (hde) for data. kernel was 2.6.19-1.2288.fc5xen0. when I added 3 more 400 GB disks (hdf to hdh) and created the raid5, the server crashed (rebooted, freezed, ...) as soon as there was more activity on the raid (kernel panics indicating trouble with interrupts, inpage errors etc.) I then upgraded to a 400W power supply, which didn't help. I went back to two single (non-raid) 400 GB disks - same problem. finally, I figured out that the non-xen kernel works without problems. I'm filling the raid5 since several hours now and the system is still stable. I haven't tried to re-create the raid5 using the non-xen kernel, it was created using the xen kernel. maybe xen could be the problem ? I was wrong in my last post - OS is actually fedora core 5 (sorry for the typo) PCI: Disabling Via external APIC routing I will note there is the ominous '400GB' lockup bug with certain promise controllers. With the Promise ATA/133 controllers in some configurations you will get a DRQ/lockup no matter what, replacing with an ATA/100 card and no issues. But I see you have a 20265 with is an ATA/100 promise/chipset. Just out of curiosity have you tried writing or running badblocks on each parition simultaenously, this would simulate (somewhat) the I/O sent/received to the drives during a RAID5 rebuild. Justin. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this raid5 OK ?
-wheneverRainer Fuegenstein wrote: Bill Davidsen wrote: This still looks odd, why should it behave like this. I have created a lot of arrays (when I was doing the RAID5 speed testing thread), and never had anything like this. I'd like to see dmesg to see if there was an error reported regarding this. I think there's more going on, the original post showed the array as up rather than some building status, also indicates some issue, perhaps. What is the partition type of each of these partitions? Perhaps there's a clue there. partition type is FD (linux raid autodetect) on all disks. here's some more info: the hardware is pretty old, an 800MHz ASUS board with AMD cpu and an extra onboard promise IDE controller with two channels. the server was working well with a 60 GB hda disk (system) and a single 400 GB disk (hde) for data. kernel was 2.6.19-1.2288.fc5xen0. when I added 3 more 400 GB disks (hdf to hdh) and created the raid5, the server crashed (rebooted, freezed, ...) as soon as there was more activity on the raid (kernel panics indicating trouble with interrupts, inpage errors etc.) I then upgraded to a 400W power supply, which didn't help. I went back to two single (non-raid) 400 GB disks - same problem. finally, I figured out that the non-xen kernel works without problems. I'm filling the raid5 since several hours now and the system is still stable. I haven't tried to re-create the raid5 using the non-xen kernel, it was created using the xen kernel. maybe xen could be the problem ? I think it sounds likely at this point, I have been having issues with xen FC6 kernels, so perhaps the build or testing environment has changed. However, I would round up the usual suspects, check all cables tight, check master/slave jumper settings on drives, etc. Be sure you have the appropriate cables, 80 pin where needed. Unless you need the xen kernel you might be better off without it for now. The rest of your details were complete but didn't give me a clue, sorry. I was wrong in my last post - OS is actually fedora core 5 (sorry for the typo) current state of the raid5: [EMAIL PROTECTED] ~]# mdadm --detail --scan ARRAY /dev/md0 level=raid5 num-devices=4 spares=1 UUID=e96cd8fe:c56c3438:6d9b6c14:9f0eebda [EMAIL PROTECTED] ~]# mdadm --misc --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Fri Mar 30 15:55:42 2007 Raid Level : raid5 Array Size : 1172126208 (1117.83 GiB 1200.26 GB) Device Size : 390708736 (372.61 GiB 400.09 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Fri Mar 30 20:22:27 2007 State : active, degraded, recovering Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 64K Rebuild Status : 12% complete UUID : e96cd8fe:c56c3438:6d9b6c14:9f0eebda Events : 0.26067 Number Major Minor RaidDevice State 0 3310 active sync /dev/hde1 1 33 651 active sync /dev/hdf1 2 3412 active sync /dev/hdg1 4 34 653 spare rebuilding /dev/hdh1 here's the dmesg of the last reboot (when the raid was already created, but still syncing): [ since it told me nothing useful I deleted it ] -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this raid5 OK ?
Justin Piszcz wrote: On Fri, 30 Mar 2007, Rainer Fuegenstein wrote: Bill Davidsen wrote: This still looks odd, why should it behave like this. I have created a lot of arrays (when I was doing the RAID5 speed testing thread), and never had anything like this. I'd like to see dmesg to see if there was an error reported regarding this. I think there's more going on, the original post showed the array as up rather than some building status, also indicates some issue, perhaps. What is the partition type of each of these partitions? Perhaps there's a clue there. partition type is FD (linux raid autodetect) on all disks. here's some more info: the hardware is pretty old, an 800MHz ASUS board with AMD cpu and an extra onboard promise IDE controller with two channels. the server was working well with a 60 GB hda disk (system) and a single 400 GB disk (hde) for data. kernel was 2.6.19-1.2288.fc5xen0. when I added 3 more 400 GB disks (hdf to hdh) and created the raid5, the server crashed (rebooted, freezed, ...) as soon as there was more activity on the raid (kernel panics indicating trouble with interrupts, inpage errors etc.) I then upgraded to a 400W power supply, which didn't help. I went back to two single (non-raid) 400 GB disks - same problem. finally, I figured out that the non-xen kernel works without problems. I'm filling the raid5 since several hours now and the system is still stable. I haven't tried to re-create the raid5 using the non-xen kernel, it was created using the xen kernel. maybe xen could be the problem ? I was wrong in my last post - OS is actually fedora core 5 (sorry for the typo) PCI: Disabling Via external APIC routing I will note there is the ominous '400GB' lockup bug with certain promise controllers. With the Promise ATA/133 controllers in some configurations you will get a DRQ/lockup no matter what, replacing with an ATA/100 card and no issues. But I see you have a 20265 with is an ATA/100 promise/chipset. Just out of curiosity have you tried writing or running badblocks on each parition simultaenously, this would simulate (somewhat) the I/O sent/received to the drives during a RAID5 rebuild. These are all things which could be related, but any clue why the non-xen kernel works? -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
is this raid5 OK ?
hi, I manually created my first raid5 on 4 400 GB pata harddisks: [EMAIL PROTECTED] ~]# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 --spare-devices=0 /dev/hde1 /dev/hdf1 /dev/hdg1 /dev/hdh1 mdadm: layout defaults to left-symmetric mdadm: chunk size defaults to 64K mdadm: size set to 390708736K mdadm: array /dev/md0 started. but, mdstat shows: [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdh1[4] hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] unused devices: none I'm surprised to see that there's one failed device [UUU_] ? shouldn't it read [] ? [EMAIL PROTECTED] ~]# mdadm --detail --scan mdadm --misc --detail /dev/md0 mdadm: cannot open mdadm: No such file or directory /dev/md0: Version : 00.90.03 Creation Time : Thu Mar 29 19:21:29 2007 Raid Level : raid5 Array Size : 1172126208 (1117.83 GiB 1200.26 GB) Device Size : 390708736 (372.61 GiB 400.09 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Thu Mar 29 19:37:07 2007 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K UUID : 08c98d1b:d0b5614d:d6893163:61d4bf1b Events : 0.596 Number Major Minor RaidDevice State 0 3310 active sync /dev/hde1 1 33 651 active sync /dev/hdf1 2 3412 active sync /dev/hdg1 2 000 removed 4 34 654 active sync /dev/hdh1 ... and why is there a removed entry ? sorry if these questions are stupid, but this is my first raid5 and I'm a bit worried. cu - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this raid5 OK ?
On Thu, 29 Mar 2007, Rainer Fuegenstein wrote: hi, I manually created my first raid5 on 4 400 GB pata harddisks: [EMAIL PROTECTED] ~]# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 --spare-devices=0 /dev/hde1 /dev/hdf1 /dev/hdg1 /dev/hdh1 mdadm: layout defaults to left-symmetric mdadm: chunk size defaults to 64K mdadm: size set to 390708736K mdadm: array /dev/md0 started. but, mdstat shows: [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdh1[4] hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] unused devices: none I'm surprised to see that there's one failed device [UUU_] ? shouldn't it read [] ? [EMAIL PROTECTED] ~]# mdadm --detail --scan mdadm --misc --detail /dev/md0 mdadm: cannot open mdadm: No such file or directory /dev/md0: Version : 00.90.03 Creation Time : Thu Mar 29 19:21:29 2007 Raid Level : raid5 Array Size : 1172126208 (1117.83 GiB 1200.26 GB) Device Size : 390708736 (372.61 GiB 400.09 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Thu Mar 29 19:37:07 2007 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K UUID : 08c98d1b:d0b5614d:d6893163:61d4bf1b Events : 0.596 Number Major Minor RaidDevice State 0 3310 active sync /dev/hde1 1 33 651 active sync /dev/hdf1 2 3412 active sync /dev/hdg1 2 000 removed 4 34 654 active sync /dev/hdh1 ... and why is there a removed entry ? sorry if these questions are stupid, but this is my first raid5 and I'm a bit worried. cu - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Strange, it should read [].. Correct, I would mdadm --zero-superblock on all those drives and re-create the array (mdadm -S (stop it first)) of course before you do it. Justin. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this raid5 OK ?
On Thursday March 29, [EMAIL PROTECTED] wrote: hi, I manually created my first raid5 on 4 400 GB pata harddisks: [EMAIL PROTECTED] ~]# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 --spare-devices=0 /dev/hde1 /dev/hdf1 /dev/hdg1 /dev/hdh1 mdadm: layout defaults to left-symmetric mdadm: chunk size defaults to 64K mdadm: size set to 390708736K mdadm: array /dev/md0 started. but, mdstat shows: [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdh1[4] hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] unused devices: none I'm surprised to see that there's one failed device [UUU_] ? shouldn't it read [] ? It should read UUU_ at first while building the 4th drive (rebuilding a missing drive is faster that calculating and writing all the parity blocks). But it doesn't seem to be doing that. What kernel version? Try the latest 2.6.x.y in that series. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is this raid5 OK ?
On 3/29/07, Neil Brown [EMAIL PROTECTED] wrote: On Thursday March 29, [EMAIL PROTECTED] wrote: hi, I manually created my first raid5 on 4 400 GB pata harddisks: [EMAIL PROTECTED] ~]# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 --spare-devices=0 /dev/hde1 /dev/hdf1 /dev/hdg1 /dev/hdh1 mdadm: layout defaults to left-symmetric mdadm: chunk size defaults to 64K mdadm: size set to 390708736K mdadm: array /dev/md0 started. but, mdstat shows: [EMAIL PROTECTED] ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 hdh1[4] hdg1[2] hdf1[1] hde1[0] 1172126208 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] unused devices: none I'm surprised to see that there's one failed device [UUU_] ? shouldn't it read [] ? It should read UUU_ at first while building the 4th drive (rebuilding a missing drive is faster that calculating and writing all the parity blocks). But it doesn't seem to be doing that. What kernel version? Try the latest 2.6.x.y in that series. I have seen something similar with older versions of mdadm when specifying all the member drives at once. Does the following kick things into action? mdadm --create /dev/md0 -n 4 -l 5 /dev/hd[efg]1 missing mdadm --add /dev/md0 /dev/hdh1 -- Dan - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
