Re: [PATCH 00/19] Hardware Accelerated MD RAID5: Introduction
On Wed, Sep 13, 2006 at 12:17:55PM -0700, Dan Williams wrote: ... 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. Ok, nice :) That being said, array resync is a special case, so your mileage may vary with other applications. Every-day usage I/O performance data would be nice indeed :) I will put together some data from bonnie++, iozone, maybe contest, and post it on SourceForge. Great! -- / 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?
Tejun == Tejun Heo [EMAIL PROTECTED] writes: Tejun Would it be better for md to listen to Tejun hotplug events and auto-remove dead devices or is it Tejun something which belongs to userland? From my perspective (User+Admin), I'd _very much_ like to have (physically) removed disks be removed by md. This would greatly help me when a disk fails on any of my systems. They are all SPARC's (with a few x86). None of which have any monitor attached. The x86's have, but that monitor is a couple of hundred meters away... So when I change drive, I first have to telnet into the terminal switch port for that machine, do the mdadm commands. Then physically change the drive. Then back to a machine and telnet back in to the machine and hot-add the disk Granted, it don't take that much time, but it's a couple of extra steps (literally :) that I'd prefer not to do/take... -- supercomputer toluene Mossad Semtex assassination Noriega Rule Psix cryptographic critical NORAD terrorist killed fissionable Marxist genetic [See http://www.aclu.org/echelonwatch/index.html for more about this] [Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf] If neither of these works, try http://www.aclu.org and search for echelon. Note. This is a real, not fiction. http://www.theregister.co.uk/2001/09/06/eu_releases_echelon_spying_report/ http://www.aclu.org/safefree/nsaspying/23989res20060131.html#echelon - 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 all, On 9/13/06, Tejun Heo [EMAIL PROTECTED] wrote: Ric Wheeler wrote: Leon Woestenberg wrote: 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. 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. I did further testing of the ideas set out in this thread. Although I can use (1) static device nodes, or (2) persistent naming with the proper udev rules, each has its own kind of problems with md. As long as the kernel announces drives as disappeared but md still holds a lock, replugging drives will map to other major:minor number no matter what I try in userspace. Static device nodes will therefore not help me select the drive that was unplugged/plugged per se. Persistent naming using udev works OK (I used /dev/bay0 through /dev/bay3 to pinpoint the drive bays) but these disappear upon unplugging, while md keeps a lock to the major:minor, so replugging will move it to different major:minor numbers. So the question remains: How will hotplug and md work together? How does md and hotplug work together for current hotplug devices? 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 *exisiting* array from knoppix
mdadm --assemble /dev/md0 /dev/hda1 /dev/hdb1 # i think, man mdadm Not what I meant: there already exists an array on a file server that was created from the server os, I want to boot that server from knoppix instead and access the array. exactly what --assemble does. looks at disks, finds raid components, assembles an array out of them (meaning, tells the kernel where to find the pieces) and starts it. no? did you try? read the manual? - 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 *exisiting* array from knoppix
Am Donnerstag, 14. September 2006 17:58 schrieb Tuomas Leikola: mdadm --assemble /dev/md0 /dev/hda1 /dev/hdb1 # i think, man mdadm Not what I meant: there already exists an array on a file server that was created from the server os, I want to boot that server from knoppix instead and access the array. exactly what --assemble does. looks at disks, finds raid components, assembles an array out of them (meaning, tells the kernel where to find the pieces) and starts it. no? did you try? read the manual? How about you read the rest of the thread, wisecracker? -- -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
Re: Correct way to create multiple RAID volumes with hot-spare?
Ruth Ivimey-Cook wrote: Steve, 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. Yes, that's right. Thanks Ruth. Neil (or others), what is the recommended way to have the array start up if you use whole drives instead of partitions? Do you put mdadm -A etc. in rc.local? Thanks, Steve - 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 *exisiting* array from knoppix
On 9/14/06, Dexter Filmore [EMAIL PROTECTED] wrote: How about you read the rest of the thread, wisecracker? sorry. mailreader-excuse/ - 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: Correct way to create multiple RAID volumes with hot-spare?
On Thursday September 14, [EMAIL PROTECTED] wrote: Neil (or others), what is the recommended way to have the array start up if you use whole drives instead of partitions? Do you put mdadm -A etc. in rc.local? I would use mdadm -As is rc.local (or /etc/init.d/mdadm or whatever) whether using partitions or not, but maybe that is just me. This combined with correct information in mdadm.conf gets it reliably right every time. 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: raidhotadd works, mdadm --add doesn't
Leon Avery wrote: I've been using RAID for a long time, but have been using the old raidtools. Having just discovered mdadm, I want to switch, but I'm having trouble. I'm trying to figure out how to use mdadm to replace a failed disk. Here is my /proc/mdstat: Personalities : [linear] [raid1] read_ahead 1024 sectors md5 : active linear md3[1] md4[0] 1024504832 blocks 64k rounding md4 : active raid1 hdf5[0] hdh5[1] 731808832 blocks [2/2] [UU] md3 : active raid1 hde5[0] hdg5[1] 292696128 blocks [2/2] [UU] md2 : active raid1 hda5[0] hdc5[1] 48339456 blocks [2/2] [UU] md0 : active raid1 hda3[0] hdc3[1] 9765376 blocks [2/2] [UU] unused devices: none The relevant parts are md0 and md2. Physical disk hda failed, which left md0 and md2 running in degraded mode. Having an old spare used disk sitting on the shelf, I plugged it in, repartitioned it, and said mdadm --add /dev/md0 /dev/hda3 Did you remove the hda from the array first? This appeared to work, but when I looked at mdstat, hda3 was marked as failed, and md0 was still running degraded. I then foolishly tried mdadm --add /dev/md0 /dev/hda3 --run That caused a kernel panic and crashed my system. I rebooted and said raidhotadd /dev/md0 /dev/hda3 That worked perfectly, and reconstruction started immediately. So, although I don't actually have a problem at the moment, I still haven't figured out how to make mdadm hot-add a replacement disk. Examination of the syslog was interesting if not exactly informative. Here's the relevant extract from the attempt to use mdadm: Sep 10 06:50:28 eatworms kernel: md: trying to hot-add hda3 to md0 ... Sep 10 06:50:28 eatworms kernel: md: bindhda3,2 Sep 10 06:50:28 eatworms kernel: RAID1 conf printout: Sep 10 06:50:28 eatworms kernel: --- wd:1 rd:2 nd:1 Sep 10 06:50:28 eatworms kernel: disk 0, s:0, o:0, n:0 rd:0 us:1 dev:[dev 00:00] Sep 10 06:50:28 eatworms kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdc3 ...snip... Sep 10 06:50:28 eatworms kernel: RAID1 conf printout: Sep 10 06:50:28 eatworms kernel: --- wd:1 rd:2 nd:2 Sep 10 06:50:28 eatworms kernel: disk 0, s:0, o:0, n:0 rd:0 us:1 dev:[dev 00:00] Sep 10 06:50:28 eatworms kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdc3 Sep 10 06:50:28 eatworms kernel: disk 2, s:1, o:0, n:2 rd:2 us:1 dev:hda3 ...snip... Sep 10 06:50:28 eatworms kernel: md: updating md0 RAID superblock on device Sep 10 06:50:28 eatworms kernel: md: hda3 [events: 038c]6(write) hda3's sb offset: -64 Sep 10 06:50:28 eatworms kernel: attempt to access beyond end of device Sep 10 06:50:28 eatworms kernel: 03:03: rw=1, want=2147483588, limit=1 Sep 10 06:50:28 eatworms kernel: md: write_disk_sb failed for device hda3 ...followed by several retries of this before giving up The problem seems to be the negative superblock offset. In contrast, the section after the raidhotadd looks like this: Sep 10 07:12:29 eatworms kernel: md: trying to hot-add hda3 to md0 ... Sep 10 07:12:29 eatworms kernel: md: bindhda3,2 Sep 10 07:12:29 eatworms kernel: RAID1 conf printout: Sep 10 07:12:29 eatworms kernel: --- wd:1 rd:2 nd:1 Sep 10 07:12:29 eatworms kernel: disk 0, s:0, o:0, n:0 rd:0 us:1 dev:[dev 00:00] Sep 10 07:12:29 eatworms kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdc3 ...snip... Sep 10 07:12:29 eatworms kernel: RAID1 conf printout: Sep 10 07:12:29 eatworms kernel: --- wd:1 rd:2 nd:2 Sep 10 07:12:29 eatworms kernel: disk 0, s:0, o:0, n:0 rd:0 us:1 dev:[dev 00:00] Sep 10 07:12:29 eatworms kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdc3 Sep 10 07:12:29 eatworms kernel: disk 2, s:1, o:0, n:2 rd:2 us:1 dev:hda3 ...snip... Sep 10 07:12:29 eatworms kernel: md: updating md0 RAID superblock on device Sep 10 07:12:29 eatworms kernel: md: hda3 [events: 0459]6(write) hda3's sb offset: 9765440 Sep 10 07:12:29 eatworms kernel: md: hdc3 [events: 0459]6(write) hdc3's sb offset: 9765440 Here we have a reasonable offset of 9765440 and everything works fine. I suppose this could be an mdadm bug, but it seems more likely that I'm doing something stupid. Could someone enlighten me? My system config (uname -a): Linux eatworms.swmed.edu 2.4.22e #1 Tue Feb 17 13:37:36 CST 2004 i686 unknown unknown GNU/Linux -- Leon Avery(214) 648-4931 (voice) Department of Molecular Biology-1488 (fax) University of Texas Southwestern Medical Center 6000 Harry Hines Blvd[EMAIL PROTECTED] Dallas, TX 75390-9148 http://eatworms.swmed.edu/~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
Re: PROBLEM: system crash on AMD64 with 2.6.17.11 while accessing 3TB Software-RAID5
Ralf Herrmann wrote: Dear Mr. Davidson and Mr. Brown, It certainly is a legitimate question, and marginal power would have been at the end of my list as well... However, if all else fails, try formatting the new drives to use only the size of the old drive capacity (RAID on small partitions) and see if that works. If so you may have found some rare size-related bug. Seems as if the new power supply did the trick. The box's been running smoothly, for about 2 days lately. I'm currently not in office, but since i didn't get emergency calls from my colleagues i assume it still works. Thanks again for your time, Thanks for letting us know what it was. Even if it was not the first thing we suggested. ;-) -- 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: RAID5 producing fake partition table on single drive
Lem wrote: On Mon, 2006-09-04 at 13:55 -0400, Bill Davidsen wrote: May I belatedly say that this is sort-of a kernel issue, since /proc/partitions reflects invalid data? Perhaps a boot option like nopart=sda,sdb or similar would be in order? Is this an argument to be passed to the kernel at boot time? It didn't work for me. My suggestion was to Neil or other kernel maintainers. If they agree that this is worth fixing, the option could be added in the kernel. It isn't there now, I was soliciting responses on whether this was desirable. Unfortunately I see no way to avoid data in the partition table location, which looks like a partition table, from being used. -- 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: libata hotplug and md raid?
On Thu, Sep 14, 2006 at 02:24:45PM +0200, Leon Woestenberg wrote: Hello all, On 9/13/06, Tejun Heo [EMAIL PROTECTED] wrote: Ric Wheeler wrote: Leon Woestenberg wrote: 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. 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. I did further testing of the ideas set out in this thread. Although I can use (1) static device nodes, or (2) persistent naming with the proper udev rules, each has its own kind of problems with md. As long as the kernel announces drives as disappeared but md still holds a lock, replugging drives will map to other major:minor number no matter what I try in userspace. Static device nodes will therefore not help me select the drive that was unplugged/plugged per se. Persistent naming using udev works OK (I used /dev/bay0 through /dev/bay3 to pinpoint the drive bays) but these disappear upon unplugging, while md keeps a lock to the major:minor, so replugging will move it to different major:minor numbers. So the question remains: How will hotplug and md work together? How does md and hotplug work together for current hotplug devices? The answer to both of these questions is, not very well. Me and Kay have been talking with Neil Brown about this and he agrees that it needs to be fixed up. That md device needs to have proper lifetime rules and go away proper. Hopefully it gets fixed soon. thanks, greg k-h - 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
I think there is a trick to improve performance of md.
blow are some codes in md_do_sync function of md.c in linux-2.6.17.11-rc5/drivers/md 4774: int next = (last_mark+1) % SYNC_MARKS; I have no idea why SYNC_MARKS is set 10. if set SYNC_MARKS to 8 or 16(the power of 2), we can replace the % operation to operation and this trick will accelerate the running of this code. - 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
