Re: linear writes to raid5
On Saturday April 8, [EMAIL PROTECTED] wrote: > > Good day all, > > is there a way to batch explicitely write requests raid5 issues? > for example, there is a raid5 built from 3 disks with chunk=64K. > one types dd if=/dev/zero of=/dev/md0 bs=128k count=1 and 128K > bio gets into the raid5. raid5 processes the request, does xor > for parity stripe, then issues 2 64KB requests down to lower level. > > is it even possible to implement? if so, how complex? > > I suppose we could introduce a context which holds last > non-issued bio and instead of generic_make_request() in > handle_stripe() try to merge current request to the previous > one from the context? how does this sound to you? The raid5 code attempts to do this already, though I'm not sure how successful it is. I think it is fairly successful, but not completely successful. There is a trade-off that raid5 has to make. Waiting longer can mean more blocks on the same stripe, and so less reads. But waiting longer can also increase latency which might not be good. The thing to would be to put some tracing in to find out exactly what is happening for some sample workloads, and then see if anything can be improved. 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: Can't mount /dev/md0 after stopping a synchronization
On 4/8/06, Mike Garey <[EMAIL PROTECTED]> wrote: > I have one last question though.. When I update /boot/grub/menu.lst > while booted from /dev/md0 with both disks available, does this file > get written to the MBR on both disks, or do I have to do this > manually? > Grub's configuration lives on both mirrors, as it's in the filesystem, not in MBR. At boot time, grub kinda "mounts" the filesystem and reads the configuration from there. (grub doesn't understand the mirror, but it doesn't need to) - 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: linear writes to raid5
> is there a way to batch explicitely write requests raid5 issues? sort of like TCP_CORK? > for example, there is a raid5 built from 3 disks with chunk=64K. > one types dd if=/dev/zero of=/dev/md0 bs=128k count=1 OK, so this is an aligned, whole-stripe write. >and 128K > bio gets into the raid5. raid5 processes the request, does xor > for parity stripe, then issues 2 64KB requests down to lower level. don't you mean _3_ chunk-sized writes? if so, are you actually asking about the case when you issue an aligned two-stripe write? (which might get broken into 6 64K writes, not sure, rather than three 2-chunk writes...) _not_ that I know this code at all! - 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: A failed-disk-how-to anywhere?
I'm sorry - I replied to Brad's email a few hours ago, but I was a bit too fast, and didn't notice I was replying to his personal account. Here's my reply - as you can see, all is fine now! Thank you both! (doing a '#cat /proc/mdstat', show that everything went well) Martin Hello Brad You got very close ... :-) Thank you! I swapped the IDE-cables, and the thing booted nicely! So from within webmin (I know ... but it's easy to use) I created three new linux raid partitions on the new drive, and - also from webmin - added those to the array. Running a #top - I can see some re-syncing is going on - so I guess everything is fine! Big thanks! Martin On 09/04/2006, at 20.12, Mike Hardy wrote: Brad Campbell wrote: Martin Stender wrote: Hi there! I have two identical disks sitting on a Promise dual channel IDE controller. I guess both disks are primary's then. One of the disks have failed, so I bought a new disk, took out the failed disk, and put in the new one. That might seem a little naive, and apparently it was, since the system won't boot up now. It boots fine, when only the old, healthy disk is connected. My initial thought would be you have hde and hdg in a raid-1 and nothing on the on-board controllers. hde has failed and when you removed it your controller tried the 1st disk it could find (hdg) to boot of.. Bingo.. away we go. You plug a new shiny disk into hde and now the controller tries to boot off that, except it's blank and therefore a no-go. I'd either try and force the controller to boot off hdg (which might be a controller bios option) or swap hde & hdg.. then it might boot and let you create your partitions on hdg and then add it back into the mirror. I'd add another stab in the dark and guess that you didn't install your boot loader on both drives. Not that I've ever done that before (ok, a few times, most recently two days ago, sigh) Typically the BIOS will try all hard drives and so it should have rolled to one that worked, but if only the "failed" drive had the boot loader then you are of course not bootable. I solved this by booting rescue mode, starting up the raid arrays, mounting them, and manually grub installing. Here's a good page for the grub incantations: http://gentoo-wiki.com/ HOWTO_Gentoo_Install_on_Software_RAID_mirror_and_LVM2_on_top_of_RAID#B ootloader_installation_and_configuration -Mike - 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: A failed-disk-how-to anywhere?
Brad Campbell wrote: > Martin Stender wrote: > >> Hi there! >> >> I have two identical disks sitting on a Promise dual channel IDE >> controller. I guess both disks are primary's then. >> >> One of the disks have failed, so I bought a new disk, took out the >> failed disk, and put in the new one. >> That might seem a little naive, and apparently it was, since the >> system won't boot up now. >> It boots fine, when only the old, healthy disk is connected. > My initial thought would be you have hde and hdg in a raid-1 and nothing > on the on-board controllers. hde has failed and when you removed it your > controller tried the 1st disk it could find (hdg) to boot of.. Bingo.. > away we go. > You plug a new shiny disk into hde and now the controller tries to boot > off that, except it's blank and therefore a no-go. > > I'd either try and force the controller to boot off hdg (which might be > a controller bios option) or swap hde & hdg.. then it might boot and let > you create your partitions on hdg and then add it back into the mirror. I'd add another stab in the dark and guess that you didn't install your boot loader on both drives. Not that I've ever done that before (ok, a few times, most recently two days ago, sigh) Typically the BIOS will try all hard drives and so it should have rolled to one that worked, but if only the "failed" drive had the boot loader then you are of course not bootable. I solved this by booting rescue mode, starting up the raid arrays, mounting them, and manually grub installing. Here's a good page for the grub incantations: http://gentoo-wiki.com/HOWTO_Gentoo_Install_on_Software_RAID_mirror_and_LVM2_on_top_of_RAID#Bootloader_installation_and_configuration -Mike - 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: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11
On Sun, Apr 09, 2006 at 02:35:53PM +0200, Marc L. de Bruin wrote: Hi, (I just subscribed, sorry if this is a dupe. I did try to match the subject from the archives, but couldn't find any...) I ran into trouble after upgrading a Debian Sarge system from 2.6.11 to 2.6.15. To be more precise, it turned out that md/mdadm seems to not function properly during the boot process of 2.6.15. My /etc/mdadm/mdadm.conf contains this: >>>---[mdadm.conf]--- DEVICE /dev/hdi1 /dev/hdg1 /dev/hdc1 ARRAY /dev/md1 level=raid5 num-devices=3 UUID=09c58ab6:f706e37b:504cf890:1a597046 devices=/dev/hdi1,/dev/hdg1,/dev/hdc1 DEVICE /dev/hdg2 /dev/hdc2 ARRAY /dev/md2 level=raid1 num-devices=2 UUID=86210844:6abbf533:dc82f982:fe417066 devices=/dev/hdg2,/dev/hdc2 DEVICE /dev/hda2 /dev/hdb2 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=da619c37:6c072dc8:52e45423:f4a58b7c devices=/dev/hda2,/dev/hdb2 DEVICE /dev/hda1 /dev/hdb1 ARRAY /dev/md4 level=raid1 num-devices=2 UUID=bfc30f9b:d2c21677:c4ae5f90:b2bddb75 devices=/dev/hda1,/dev/hdb1 DEVICE /dev/hdc3 /dev/hdg3 ARRAY /dev/md3 level=raid1 num-devices=2 UUID=fced78ce:54f00a78:8662e7eb:2ad01d0b devices=/dev/hdc3,/dev/hdg3 >>>---[/mdadm.conf]--- replace all DEVICE . lines with a single DEVICE partitions remove all the device=... part from the array lines. L. - 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: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11
On Sun, 9 Apr 2006, Marc L. de Bruin wrote: ... > Okay, just pressing Control-D continues the boot process and AFAIK the root > filesystemen actually isn't corrupt. Running e2fsck returns no errors and > booting 2.6.11 works just fine, but I have no clue why it picked the wrong > partitions to build md[01234]. > > What could have happened here? i didn't know sarge had 2.6.11 or 2.6.15 packages... but i'm going to assume you've installed one of initramfs-tools or yaird in order to use the unstable 2.6.11 or 2.6.15 packages... so my comments might not apply. initramfs-tools generates an "mdrun /dev" which starts all the raids it can find... but does not include the mdadm.conf in the initrd so i'm not sure it will necessarily start them in the right minor devices. try doing an "mdadm --examine /dev/xxx" on some of your partitions to see if the "preferred minor" is what you expect it to be... if the preferred minors are wrong there's some mdadm incantation to update them... see the man page. or switch to yaird (you'll have to install yaird and purge initramfs-tools) and dpkg-reconfigure your kernel packages to cause the initrds to be rebuilt. yaird starts only the raid required for the root filesystem, and specifies the correct minor for it. then later after the initrd /etc/init.d/mdadm-raid will start the rest of your raids using your mdadm.conf. -dean - 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: A failed-disk-how-to anywhere?
Martin Stender wrote: Hi there! I have two identical disks sitting on a Promise dual channel IDE controller. I guess both disks are primary's then. One of the disks have failed, so I bought a new disk, took out the failed disk, and put in the new one. That might seem a little naive, and apparently it was, since the system won't boot up now. It boots fine, when only the old, healthy disk is connected. By the way, all three partitions are raided - including /boot ... Anyway, I have removed the old disk from the Raid with: #mdadm /dev/mdo --remove /dev/hde1 #mdadm /dev/md1 --remove /dev/hde2 #mdadm /dev/md2 --remove /dev/hde3 - but the the problem persists. I can't seem to find a decent 'How-To' - so how it this supposed to be done? A little more info would be helpful. How does the machine boot? How are your other disks configured? Are you booting off the Promise board or on-board controller (making assumptions given your promise appears to contain hde, I'm assuming hd[abcd] are on board somewhere..) I'm going to take a wild stab in the dark now.. My initial thought would be you have hde and hdg in a raid-1 and nothing on the on-board controllers. hde has failed and when you removed it your controller tried the 1st disk it could find (hdg) to boot of.. Bingo.. away we go. You plug a new shiny disk into hde and now the controller tries to boot off that, except it's blank and therefore a no-go. I'd either try and force the controller to boot off hdg (which might be a controller bios option) or swap hde & hdg.. then it might boot and let you create your partitions on hdg and then add it back into the mirror. How close did I get ? Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams - 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
A failed-disk-how-to anywhere?
Hi there! I have two identical disks sitting on a Promise dual channel IDE controller. I guess both disks are primary's then. One of the disks have failed, so I bought a new disk, took out the failed disk, and put in the new one. That might seem a little naive, and apparently it was, since the system won't boot up now. It boots fine, when only the old, healthy disk is connected. By the way, all three partitions are raided - including /boot ... Anyway, I have removed the old disk from the Raid with: #mdadm /dev/mdo --remove /dev/hde1 #mdadm /dev/md1 --remove /dev/hde2 #mdadm /dev/md2 --remove /dev/hde3 - but the the problem persists. I can't seem to find a decent 'How-To' - so how it this supposed to be done? Thanks in advance! Martin - 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
md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11
Hi, (I just subscribed, sorry if this is a dupe. I did try to match the subject from the archives, but couldn't find any...) I ran into trouble after upgrading a Debian Sarge system from 2.6.11 to 2.6.15. To be more precise, it turned out that md/mdadm seems to not function properly during the boot process of 2.6.15. My /etc/mdadm/mdadm.conf contains this: >>>---[mdadm.conf]--- DEVICE /dev/hdi1 /dev/hdg1 /dev/hdc1 ARRAY /dev/md1 level=raid5 num-devices=3 UUID=09c58ab6:f706e37b:504cf890:1a597046 devices=/dev/hdi1,/dev/hdg1,/dev/hdc1 DEVICE /dev/hdg2 /dev/hdc2 ARRAY /dev/md2 level=raid1 num-devices=2 UUID=86210844:6abbf533:dc82f982:fe417066 devices=/dev/hdg2,/dev/hdc2 DEVICE /dev/hda2 /dev/hdb2 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=da619c37:6c072dc8:52e45423:f4a58b7c devices=/dev/hda2,/dev/hdb2 DEVICE /dev/hda1 /dev/hdb1 ARRAY /dev/md4 level=raid1 num-devices=2 UUID=bfc30f9b:d2c21677:c4ae5f90:b2bddb75 devices=/dev/hda1,/dev/hdb1 DEVICE /dev/hdc3 /dev/hdg3 ARRAY /dev/md3 level=raid1 num-devices=2 UUID=fced78ce:54f00a78:8662e7eb:2ad01d0b devices=/dev/hdc3,/dev/hdg3 >>>---[/mdadm.conf]--- On 2.6.11, it booted (and still boots) correctly. The interesting parts from the boot-sequence are: >>>---[2.6.11 dmesg]--- md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: raid1 personality registered as nr 3 [...] md: md0 stopped. md: bind md: bind [...] md: md1 stopped. md: bind md: bind md: bind raid5: automatically using best checksumming function: pIII_sse pIII_sse : 3872.000 MB/sec raid5: using function: pIII_sse (3872.000 MB/sec) md: raid5 personality registered as nr 4 raid5: device hdi1 operational as raid disk 0 raid5: device hdc1 operational as raid disk 2 raid5: device hdg1 operational as raid disk 1 raid5: allocated 3161kB for md1 raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2 RAID5 conf printout: --- rd:3 wd:3 fd:0 disk 0, o:1, dev:hdi1 disk 1, o:1, dev:hdg1 disk 2, o:1, dev:hdc1 md: md2 stopped. md: bind md: bind raid1: raid set md2 active with 2 out of 2 mirrors md: md4 stopped. md: bind md: bind raid1: raid set md4 active with 2 out of 2 mirrors md: md3 stopped. md: bind md: bind raid1: raid set md3 active with 2 out of 2 mirrors >>>---[/2.6.11 dmesg]--- This all looks great and is as expected by the mdadm.conf file. The bootlog daemon continues to report ordinary things such as: >>>---[2.6.11 bootlog]--- Sat Apr 8 16:47:53 2006: bootlogd. Sat Apr 8 16:47:53 2006: Setting parameters of disc: (none). Sat Apr 8 16:47:53 2006: Activating swap. Sat Apr 8 16:47:53 2006: Checking root file system... Sat Apr 8 16:47:53 2006: fsck 1.37 (21-Mar-2005) Sat Apr 8 16:47:53 2006: /: clean, 122183/524288 files, 508881/1048576 blocks [...] Sat Apr 8 14:47:55 2006: Creating device-mapper devices...done. Sat Apr 8 14:47:55 2006: Creating device-mapper devices...done. Sat Apr 8 14:47:56 2006: Starting raid devices: mdadm-raid5: Sat Apr 8 14:47:56 2006: mdadm: /dev/md1 has been started with 3 drives. Sat Apr 8 14:47:56 2006: mdadm: /dev/md2 has been started with 2 drives. Sat Apr 8 14:47:56 2006: mdadm: /dev/md4 has been started with 2 drives. Sat Apr 8 14:47:56 2006: mdadm: /dev/md3 has been started with 2 drives. Sat Apr 8 14:47:56 2006: done. Sat Apr 8 14:47:56 2006: Setting up LVM Volume Groups... Sat Apr 8 14:47:57 2006: Reading all physical volumes. This may take a while... Sat Apr 8 14:47:58 2006: Found volume group "vg" using metadata type lvm2 Sat Apr 8 14:47:58 2006: 2 logical volume(s) in volume group "vg" now active Sat Apr 8 14:47:58 2006: Checking all file systems... Sat Apr 8 14:47:58 2006: fsck 1.37 (21-Mar-2005) Sat Apr 8 14:47:58 2006: /dev/md4: clean, 54/48192 files, 43630/192640 blocks Sat Apr 8 14:47:58 2006: /dev/mapper/vg-home: clean, 7560/219520 files, 120502/438272 blocks Sat Apr 8 14:47:58 2006: /dev/md1: clean, 38614/9781248 files, 15097260/19539008 blocks Sat Apr 8 14:47:58 2006: /dev/md2: clean, 18/7325696 files, 8634921/14651264 blocks Sat Apr 8 14:47:58 2006: /dev/md3: clean, 2079183/7094272 files, 10865102/14185376 blocks Sat Apr 8 14:47:58 2006: /dev/hde1: clean, 74/28640 files, 26855696/29296527 blocks Sat Apr 8 14:47:58 2006: /dev/hde2: clean, 573/9781248 files, 13186560/19543072 blocks Sat Apr 8 14:47:58 2006: Setting kernel variables ... Sat Apr 8 14:47:58 2006: ... done. Sat Apr 8 14:47:59 2006: Mounting local filesystems... Sat Apr 8 14:47:59 2006: /dev/md4 on /boot type ext3 (rw) Sat Apr 8 14:47:59 2006: /dev/mapper/vg-home on /home type ext3 (rw) Sat Apr 8 14:47:59 2006: /dev/md1 on /mnt/raid5 type ext3 (rw) Sat Apr 8 14:47:59 2006: /dev/md2 on /mnt/others2 type ext3 (rw) Sat Apr 8 14:47:59 2006: /dev/md3 on /mnt/others type ext3 (rw) Sat Apr 8 14:47:59 2006: proc on /mnt/others/sid-chrooted/proc type proc (rw) Sat Apr 8 14:47:59 2006: /dev/hde1 on /mnt/vmsdata type ext3 (rw) Sat Apr 8 14:47:59 2006: /dev/hde2 on /mnt/vms type ext3 (rw) Sat Apr 8 14:47:
