Re: mdadm 2.1: command line option parsing bug?
Neil Brown wrote: [] I would like it to take an argument in contexts where --bitmap was meaningful (Create, Assemble, Grow) and not where --brief is meaningful (Examine, Detail). but I don't know if getopt_long will allow the 'short_opt' string to be changed half way through processing... getopt allows you to change both long and short options set before every call (provided argvargc are intact). But. Please, pretty please, don't implement the same options with different meaning. It's confusing at best. Assign short options to frequently-used commands, and leave only long options for the rest. I dunno whichever of --brief or --bitmap is more frequent, I'd say both can be long-only, but since -b already stands for --brief, don't use it for --bitmap. At the very least, I can print a message if '-b' is being interpreted as as --brief, but the option argument is present. -a has the same problem (--add vs --auto). And this is also bad. In my opinion anyway. /mjt - 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: mdadm 2.1: command line option parsing bug?
Neil Brown wrote: I would like it to take an argument in contexts where --bitmap was meaningful (Create, Assemble, Grow) and not where --brief is meaningful (Examine, Detail). but I don't know if getopt_long will allow the 'short_opt' string to be changed half way through processing... Here's an honest opinion from a regular user. mdadm's command line arguments seem arcane and cryptic and unintuitive. It's difficult to grasp what combinations will actually do something worthwhile and what combinations will just yield a 'you cannot do that' output. I find myself spending 20 minutes with mdadm --help and experimenting with different commands (which shouldn't be the case when doing RAID stuff) just to do simple things like create an array or make MD assemble the devices that compose an array. I know. Not very constructive, but a POV anyway. Maybe I just do not use MD enough, and so I shouldn't complain, because the interface is really not designed for the absolute newbie. If so, then I apologize. I don't have any constructive suggestions, except to say that the way the classic Cisco interface does things works very nicely. A lot of other manufacturers has also started doing things the Cisco way. If you don't have a Cisco router available, you can fx. use a Windows XP box. Type 'netsh' in a command prompt, then 'help'. Or alternatively 'netsh help'. You get the idea :-). - 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: Poor Software RAID-0 performance with 2.6.14.2
Lars Roland wrote: I have created a stripe across two 500Gb disks located on separate IDE channels using: mdadm -Cv /dev/md0 -c32 -n2 -l0 /dev/hdb /dev/hdd the performance is awful on both kernel 2.6.12.5 and 2.6.14.2 (even with hdparm and blockdev tuning), both bonnie++ and hdparm (included below) shows a single disk operating faster than the stripe: In looking at this I found something interesting, even though you identified your problem before I was able to use the data for the intended purpose. So other than suggesting that the stripe size is too small, nothing on that, your hardware is the issue. I have two ATA drives connected, and each has two partitions. The first partition of each is mirrored for reliability with default 64k chunks, and the second is striped, with 512k chunks (I write a lot of 100MB files to this f/s). Reading the individual devices with dd, I saw a transfer rate of about 60MB/s, while the striped md1 device gave just under 120MB/s. (60.3573 and 119.6458) actually. However, the mirrored md0 also gave just 60MB/s read speed. One of the advantages of mirroring is that if there is heavy read load when one drive is busy there is another copy of the data on the other drive(s). But doing 1MB reads on the mirrored device did not show that the kernel took advantage of this in any way. In fact, it looks as if all the reads are going to the first device, even with multiple processes running. Does the md code now set write-mostly by default and only go to the redundant drives if the first fails? I won't be able to do a lot of testing until Thursday, or perhaps Wednesday night, but that is not as I expected and not what I want, I do mirroring on web and news servers to spread the head motion, now I will be looking at the stats to see if that's happening. I added the raid M/L to the addresses, since this is getting to be general RAID question. -- -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me - 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: Poor Software RAID-0 performance with 2.6.14.2
Bill Davidsen wrote: One of the advantages of mirroring is that if there is heavy read load when one drive is busy there is another copy of the data on the other drive(s). But doing 1MB reads on the mirrored device did not show that the kernel took advantage of this in any way. In fact, it looks as if all the reads are going to the first device, even with multiple processes running. Does the md code now set write-mostly by default and only go to the redundant drives if the first fails? No, it doesn't use write-mostly by default. The way raid1 read balancing works (in recent kernels) is this: - sequential reads continue to go to the first disk - for non-sequential reads, the code tries to pick the disk whose head is closest to the sector that needs to be read So even if the reads aren't exactly sequential, you probably still end up reading from the first disk most of the time. I imagine with a more random read pattern you'd see the second disk getting used. -- Paul - 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: mdadm 2.1: command line option parsing bug?
On 10:21, Neil Brown wrote: -a has the same problem (--add vs --auto). I'll see what I can do, gengetopt? (http://www.gnu.org/software/gengetopt/) Andre -- Jesus not only saves, he also frequently makes backups - 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
