Re: Correct way to create multiple RAID volumes with hot-spare?
On Tue, 2006-09-12 at 17:05 -0400, Steve Cousins wrote: The recent Messed up creating new array... thread has someone who started by using the whole drives but she now wants to use partitions because the array is not starting automatically on boot (I think that was the symptom). I'm guessing this is because there is no partigion ID of fd since there isn't even a partition. I'm on the verge of re-doing this array with 11 full drives (/dev/sd? as opposed to /dev/sd?1 and /dev/sd?2). Will I have the same problems with booting? I like the idea of not having to partition the drives but not if it is going to cause hassles. I realize that there could be a potential problem if I need to replace a drive with a slightly different model that is slightly smaller. From personal experience, partitions would be much easier. I've still got an issue on my RAID5 where one of the hard disks has a bogus/fake partition table on it (simply due to the data on the RAID appearing like a partition table). It causes problems with lilo and other processes at boot time (all non-fatal except for lilo). Perhaps with time I'll get lucky and the data in that particular part of the drive will be changed to something that looks nothing like a partition table :) Lem. - 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
libata hotplug and md raid?
Hello all, I am testing the (work-in-progress / upcoming) libata SATA hotplug. Hotplugging alone seems to work, but not well in combination with md RAID. Here is my report and a question about intended behaviour. Mainstream 2.6.17.11 kernel patched with libata-tj-2.6.17.4-20060710.tar.bz2 from http://home-tj.org/files/libata-tj-stable/. Supermicro P8SCT motherboard with Intel ICH6R, using AHCI libata driver. In short, I use ext3 over /dev/md0 over 4 SATA drives /dev/sd[a-d] each driven by libata ahci. I unplug then replug the drive that is rebuilding in RAID-5. When I unplug a drive, /dev/sda is removed, hotplug seems to work to the point where proc/mdstat shows the drive failed, but not removed. Every other notion of the drive (in kernel and udev /dev namespace) seems to be gone after unplugging. I cannot manually removed the drive using mdadm, because it tells me the drive does not exist. Replugging the drive brings it back as /dev/sde, md0 will not pick it up. The expected behaviour (from me) is that the drive re-appears as /dev/sda. What is the intended behaviour of md in this case? Should some user-space application fail-remove a drive as a pre-action of the unplug event from udev, or should md fully remove the drive within kernel space?? See kernel/udev/userspace messages in chronological order, with my actions marked between , at this web page: http://pastebin.ca/168798 Thanks, -- Leon -- Leon - 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: libata hotplug and md raid?
(Adding Tejun Greg KH to this thread) Leon Woestenberg wrote: Hello all, I am testing the (work-in-progress / upcoming) libata SATA hotplug. Hotplugging alone seems to work, but not well in combination with md RAID. Here is my report and a question about intended behaviour. Mainstream 2.6.17.11 kernel patched with libata-tj-2.6.17.4-20060710.tar.bz2 from http://home-tj.org/files/libata-tj-stable/. Supermicro P8SCT motherboard with Intel ICH6R, using AHCI libata driver. In short, I use ext3 over /dev/md0 over 4 SATA drives /dev/sd[a-d] each driven by libata ahci. I unplug then replug the drive that is rebuilding in RAID-5. When I unplug a drive, /dev/sda is removed, hotplug seems to work to the point where proc/mdstat shows the drive failed, but not removed. Every other notion of the drive (in kernel and udev /dev namespace) seems to be gone after unplugging. I cannot manually removed the drive using mdadm, because it tells me the drive does not exist. Replugging the drive brings it back as /dev/sde, md0 will not pick it up. I have a similar setup, AHCI + 4 drives but using a RAID-1 group. The thing that you are looking for is persistent device naming and should work properly if you can tweak udev/hotplug correctly. I have verified that a drive pull/drive reinsert on a mainline kernel with a SLES10 base does provide this (first insertion gives me sdb, pull followed by reinsert still is sdb), but have not tested interaction with RAID since I am focused on the bad block handling at the moment. I will add this to my list ;-) The expected behaviour (from me) is that the drive re-appears as /dev/sda. What is the intended behaviour of md in this case? Should some user-space application fail-remove a drive as a pre-action of the unplug event from udev, or should md fully remove the drive within kernel space?? See kernel/udev/userspace messages in chronological order, with my actions marked between , at this web page: http://pastebin.ca/168798 Thanks, -- Leon - 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: [PATCH 00/19] Hardware Accelerated MD RAID5: Introduction
On Mon, Sep 11, 2006 at 04:00:32PM -0700, Dan Williams wrote: Neil, ... Concerning the context switching performance concerns raised at the previous release, I have observed the following. For the hardware accelerated case it appears that performance is always better with the work queue than without since it allows multiple stripes to be operated on simultaneously. I expect the same for an SMP platform, but so far my testing has been limited to IOPs. For a single-processor non-accelerated configuration I have not observed performance degradation with work queue support enabled, but in the Kconfig option help text I recommend disabling it (CONFIG_MD_RAID456_WORKQUEUE). Out of curiosity; how does accelerated compare to non-accelerated? -- / jakob - 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: libata hotplug and md raid?
Hello Tejun et al, On 9/13/06, Tejun Heo [EMAIL PROTECTED] wrote: Ric Wheeler wrote: (Adding Tejun Greg KH to this thread) Adding linux-ide to this thread. Leon Woestenberg wrote: [--snip--] In short, I use ext3 over /dev/md0 over 4 SATA drives /dev/sd[a-d] each driven by libata ahci. I unplug then replug the drive that is rebuilding in RAID-5. When I unplug a drive, /dev/sda is removed, hotplug seems to work to the point where proc/mdstat shows the drive failed, but not removed. Yeap, that sounds about right. I suppose this is 'right', but only if we think of a hot unplugged device as a failing device. As in most cases we cannot tell if the hot unplug was intentional or not (because we see a device disappearing from the phy and we have no other sensory data available), assuming the drive 'fails' seems reasonable. Every other notion of the drive (in kernel and udev /dev namespace) seems to be gone after unplugging. I cannot manually removed the drive using mdadm, because it tells me the drive does not exist. I see. That's a problem. Can you use /dev/.static/dev/sda instead? If you can't find those static nodes, just create one w/ 'mknod my-static-sda b 8 0' and use it. Yes, that works. Also, replugging brings back the device as /dev/sda, indicating md is no longer holding the internal lock. Apart from persistent naming Ric mentioned above, the reason why you don't get sda back is md is holding the internal device. It's removed from all visible name spaces but md still holds a reference, so the device cannot be destroyed. To me, this seems a bug, as the kernel already told everyone else (userland) that it thinks the device is no longer there. This contradicts the fact that the kernel itself has dangling references to it. So, when a new device comes along, sda is occupied by the dead device, and the new one gets the next available slot, which happens to be sde in your case. What is the intended behaviour of md in this case? Should some user-space application fail-remove a drive as a pre-action of the unplug event from udev, or should md fully remove the drive within kernel space?? I'm curious too. Would it be better for md to listen to hotplug events and auto-remove dead devices or is it something which belongs to userland? ...also considering race conditions between userland and kernel in that case... My first thoughts would be that a unplugged device should be handled differently than a device that failed in other senses, or at least this should be considered by the kernel developers. Thanks for the response so far, regards, -- Leon - 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: access *existing* array from knoppix
Am Dienstag, 12. September 2006 16:08 schrieb Justin Piszcz: /dev/MAKEDEV /dev/md0 also make sure the SW raid modules etc are loaded if necessary. Won't work, MAKEDEV doesn't know how to create [/dev/]md0. mknod /dev/md0 b 9 0 perhaps? - 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: access *existing* array from knoppix
Am Mittwoch, 13. September 2006 15:48 schrieb Rob Bray: Am Dienstag, 12. September 2006 16:08 schrieb Justin Piszcz: /dev/MAKEDEV /dev/md0 also make sure the SW raid modules etc are loaded if necessary. Won't work, MAKEDEV doesn't know how to create [/dev/]md0. mknod /dev/md0 b 9 0 perhaps? Uh huh, go and try. Next boot it's gone again. running that command in /lib/udev/devices however made it permanent. Took way too long to figure tho. If the kernel devs feel like they need to hurl over a working system they better release proper docs for the replacement. And stop screwing with the syntax. (Yes, wrong list, I know...) -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(+)@ s-:+ a- C UL++ P+++ L+++ E-- W++ N o? K- w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@ b++(+++) DI+++ D- G++ e* h++ r* y? --END GEEK CODE BLOCK-- http://www.stop1984.com http://www.againsttcpa.com - 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
[PATCH] missing close in mdassemble
attached, please apply without this mdassemble cannot activate stacked arrays, i wonder how i managed to miss it :( L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ --- mdadm-2.5.3/mdassemble.c.close 2006-09-13 12:28:00.0 +0200 +++ mdadm-2.5.3/mdassemble.c2006-09-13 12:30:24.0 +0200 @@ -91,13 +91,12 @@ rv |= 1; continue; } - if (ioctl(mdfd, GET_ARRAY_INFO, array)=0) - /* already assembled, skip */ - continue; + if (ioctl(mdfd, GET_ARRAY_INFO, array) 0) rv |= Assemble(array_list-st, array_list-devname, mdfd, array_list, NULL, NULL, readonly, runstop, NULL, NULL, verbose, force); + close(mdfd); } return rv; }
Re: [PATCH 00/19] Hardware Accelerated MD RAID5: Introduction
On 9/13/06, Jakob Oestergaard [EMAIL PROTECTED] wrote: On Mon, Sep 11, 2006 at 04:00:32PM -0700, Dan Williams wrote: Neil, ... Concerning the context switching performance concerns raised at the previous release, I have observed the following. For the hardware accelerated case it appears that performance is always better with the work queue than without since it allows multiple stripes to be operated on simultaneously. I expect the same for an SMP platform, but so far my testing has been limited to IOPs. For a single-processor non-accelerated configuration I have not observed performance degradation with work queue support enabled, but in the Kconfig option help text I recommend disabling it (CONFIG_MD_RAID456_WORKQUEUE). Out of curiosity; how does accelerated compare to non-accelerated? One quick example: 4-disk SATA array rebuild on iop321 without acceleration - 'top' reports md0_resync and md0_raid5 dueling for the CPU each at ~50% utilization. With acceleration - 'top' reports md0_resync cpu utilization at ~90% with the rest split between md0_raid5 and md0_raid5_ops. The sync speed reported by /proc/mdstat is ~40% higher in the accelerated case. That being said, array resync is a special case, so your mileage may vary with other applications. I will put together some data from bonnie++, iozone, maybe contest, and post it on SourceForge. / jakob 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
