On 02/08/2011 02:22 AM, Roberto Spadim wrote: > hi guys, i made some changes to md raid1 software, could fedora test > it? for me it work very nice =) > the raid1 new code is based in kernel 2.6.37 > here is the new and old code: > www.spadim.com.br/raid1 > > just read_balance changed (4 modes: near_head(today) > round_robin(counter per mirror) stripe (like raid0, with shift for > make stripe less or more intensive), time based (depending on head > positioning time and read size it calculate the fasted mirror, some > new improvement must be done but it works, improvements= get io queue > of each mirror and many a time estimation of queue time, with it get > more close best disk) > > it´s open source please help me testing it, neil at raid kernel must > some benchmarks to put it inside kernel source > for mixed speed mirrors time based is good, > for ssd only round_Robin is good (per mirror count, put 230 for > 230mb/s, 150 for mb/s or multiples to make a good round robin) > for disks and/or ssd mixed or not, stripe is good > for disks only near head is good > Hi Roberto, You might find it's better to discuss this on the linux-raid mailing list hosted at kernel.org: http://vger.kernel.org/vger-lists.html#linux-raid The list is dedicated to discussion of RAID technologies and their use with Linux, including the kernel MD subsystem. You might also find it easier to get review and testing of your changes if you distribute them as unified diff files instead of ".old.c"/".new.c" files. Diffs or patches are the standard format for distributing and reviewing changes to source code and by using that format you make it more likely that others will test, read and comment on your code. It's also a good habit to get into to break your changes up into a series of smaller logically related changes. This makes reviewing changes and spotting bugs or errors easier and also makes it easier to get changes accepted (since hard-to-review stuff is less likely to make it in). There are some basic guidelines and answers to common questions here: http://www.kernel.org/pub/linux/docs/lkml/#s1 There's lots of documentation that goes into more detail on the process and recommended if you search around. I turned your changes into a patch that follows the usual conventions here: http://fpaste.org/Uqqy/ It's still a big patch but much easier to review in this format. Regards, Bryn. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
