Date:	Mon, 15 Oct 2007 17:51:36 -0700 (PDT)
From:	david@...g.hm
To:	Zan Lynx <zlynx@....org>
cc:	Rik van Riel <riel@...riel.com>, linux-kernel@...r.kernel.org,
	dm-devel <dm-devel@...hat.com>
Subject: Re: WANTED: kernel projects for CS students

On Mon, 15 Oct 2007, Zan Lynx wrote:

> On Sun, 2007-10-14 at 19:01 -0400, Rik van Riel wrote:
>> The kernel newbies community often gets inquiries from CS students who
>> need a project for their studies and would like to do something with
>> the Linux kernel, but would also like their code to be useful to the
>> community afterwards.
>>
>> In order to make it easier for them, I am trying to put together a
>> page with projects that:
>> - Are self contained enough that the students can implement the
>>   project by themselves, since that is often a university requirement.
>> - Are self contained enough that Linux could merge the code (maybe
>>   with additional changes) after the student has been working on it
>>   for a few months.
>> - Are large enough to qualify as a student project, luckily there is
>>   flexibility here since we get inquiries for anything from 6 week
>>   projects to 6 month projects.
>>
>> If you have ideas on what projects would be useful, please add them
>> to this page (or email me):
>>
>> http://kernelnewbies.org/KernelProjects
>
> How about this in the Device Mapper raid-1/mirror code?
> 	/* FIXME: add read balancing */
>
> That comment has been in there for many releases.  I've wanted read
> balancing for several servers and had all sorts of ideas about it, like
> adding functions to the underlying device queues to return a "queuing
> cost" to determine which is the best queue to add the read request.  I
> think that could work better for queues like CFQ than the MD
> closest-head.
>
> An implementation would also need to be benchmarked against the MD
> raid-1.
>
> Along with the time to submit it to LKML, get it reviewed and polish it
> up, it might make a good student project.

another couple of raid enhancements would be:

1. teach the system that a raid456 stripe is handled most efficiantly if 
treated as a single block of data

by this I mean that if you read one block from the stripe the system reads 
the entire stripe, so it should take this into account when doing 
read-ahead and not always throw away most of the data it read becouse it's 
outside the current readahead window (if nothing else, look at putting it 
on the tail of the LRU list instead of just forgetting it)

if you write one block of the stripe the system must read the stripe, then 
update two blocks of the stripe (the data block and the parity block), but 
if you are going to write the entire stripe out you can ignore whatever's 
there and just calculate the parity block from the data you are writing. 
this should make writing to a raid456 stripe as fast as writing to a raid0 
stripe (well, almost, you have one more block to write).


2. not directly a kernel project, create userspace tools that make 
managing raid and partitioning on linux as easy as the zfs tools


3. there is currently the ability to grow a raid56 array by adding a disk, 
but there is not the ability to take a raid5 array, add a disk and make 
the result a raid6 array.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists