On Saturday January 31, nathapl@cs.okstate.edu wrote:
As part of my Master's thesis, I am working on adding a Reed-Solomon
personality to the existing linux RAID structure and I would like some
assistance. I'll try to keep this as brief as possible, but I apologize if
it gets long-winded.
So far, I've managed to add and register a personality with md, which
involved a few minor changes to md.c and related header files, a few
changes to mdadm to allow me to access things from userland. I've
discovered the 9 functions I need to implement (make_request, run, stop,
etc), and managed to "successfully" create an md device using only stub
functions. So far so good. Just for reference, I'm using kernel
2.4.22.
I strongly agree with Peter. Base your work on 2.6, not 2.4. The
raid code is much cleaner in 2.6.
However, I can't really find concise documentation on exactly what those 9
functions are supposed to do, and under what restrictions they must do them
in. I've been studying Rubini and Corbet's _Linux Device Drivers_ book,
which goes into great detail on the responsibilities of a block device
driver, and even covers the make_request function. For now, that's what
I'm focusing on anyway.
Good. md/raid uses the make_request_fn function, not the request_fn
function like most device drivers use.
Anyway, here's my first real question: the buffer_head bh passed into
make_request obviously contains a request for that particular
device. However, this buffer_head could be the head of a linked list, with
the next element located at b_reqnext. However, all of the code I can find
that uses make_request ignores bh->b_reqnext. Is it guaranteed to be the
only request when bypassing __make_request? Also, the request_queue_t q is
also ignored. I assume this is there for use by __make_request (since it
isn't even passed to <personality>_make_request).
The buffer_head, or bio in 2.6, passed into make_request is not the
head of a linked list. b_reqnext is not defined at this point. It is
there for the make_request function to use if it wants to.
The "standard" make_request function, called __make_request, uses it
to link adjacent buffer_heads or bios together into a single request.
Various raid make_request functions use it for other purposes or not
at all.
In 2.6, the "request_queue_t *q" is passed on to the make_request_fn
as it contains a pointer to the mddev stucture.
Second question: Since <personality>_make_request doesn't alter the
request_queue_t q, it need not worry about the io_request_lock that is
stressed in the Rubini book, correct? I think I only have to worry about
locks for any internal structures/buffers I use/create.
Correct. The io_request_lock is only used by __make_request and
request_fn functions. If you define a different make_request_fn (as
md/raid does) you can use the io_request_lock for something else, or
ignore it altogether.
Third question: The raid5 thread is registered with the md
driver. Besides the code in raid5.c, what else can wake up this
thread? Anything?
No nothing (except maybe a signal being sent to it).
That's probably enough for now. I'm sure I'll have more questions down the
line, but I need a thorough understanding of what is there before I can add
anything to it.
I too would be interest to see just how you would apply reed-solomon
encoding to RAID.
NeilBrown
At 04:53 AM 1/31/2004, Neil Brown wrote:
I strongly agree with Peter. Base your work on 2.6, not 2.4. The
raid code is much cleaner in 2.6.
I'll take a look at 2.6 then and see what's different. It may not be
possible for me to use 2.6 due to restrictions on the test machines I'll be
using. I chose 2.4 because that's what was included in the distribution
I'm using, it is what my professor is using on his machines, and it is the
version covered by the Rubini book. It seemed like a logical
choice. Where's the most comprehensive list of changes 2.4->2.6 dealing
with block drivers and linux-raid?
Good. md/raid uses the make_request_fn function, not the request_fn
function like most device drivers use.
.....<snip>....
I really appreciate the answers to my questions.
I too would be interest to see just how you would apply reed-solomon
encoding to RAID.
In short, it is a distributed storage mechanism for a small (~50) group of
workstations with a central coordinating server. RS is needed for the high
levels of redundancy possible.
Now that I've got working Reed Soloman code, I need to make a decision
really quickly on whether to use 2.4 or 2.6. I've got both, and it does
look like the raid code is much cleaner in 2.6, and it also helps that
there is raid6 for 2.6, which shows me approximately where I'd need to
modify code to turn it into RS. However, I really need some documentation
on the bio structure. The bio.h file is sorely lacking comments, and, of
course, the Rubini book isn't going to help me.
Can someone point me at some documentation for the bio structure?
I strongly agree with Peter. Base your work on 2.6, not 2.4. The
raid code is much cleaner in 2.6.
The new book Linux Kernel Development and
http://lwn.net/Articles/driver-porting/
may give u some help.
ming
On Thu, 2004-02-12 at 23:35, Nathan Lewis wrote:
Now that I've got working Reed Soloman code, I need to make a decision
really quickly on whether to use 2.4 or 2.6. I've got both, and it does
look like the raid code is much cleaner in 2.6, and it also helps that
there is raid6 for 2.6, which shows me approximately where I'd need to
modify code to turn it into RS. However, I really need some documentation
on the bio structure. The bio.h file is sorely lacking comments, and, of
course, the Rubini book isn't going to help me.
Can someone point me at some documentation for the bio structure?
quoted
I strongly agree with Peter. Base your work on 2.6, not 2.4. The
raid code is much cleaner in 2.6.
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks, that looks like exactly what I was looking for.
At 08:18 AM 2/13/2004, Ming Zhang wrote:
The new book Linux Kernel Development and
http://lwn.net/Articles/driver-porting/
may give u some help.
ming
On Thu, 2004-02-12 at 23:35, Nathan Lewis wrote:
quoted
Now that I've got working Reed Soloman code, I need to make a decision
really quickly on whether to use 2.4 or 2.6. I've got both, and it does
look like the raid code is much cleaner in 2.6, and it also helps that
there is raid6 for 2.6, which shows me approximately where I'd need to
modify code to turn it into RS. However, I really need some documentation
on the bio structure. The bio.h file is sorely lacking comments, and, of
course, the Rubini book isn't going to help me.
Can someone point me at some documentation for the bio structure?
quoted
I strongly agree with Peter. Base your work on 2.6, not 2.4. The
raid code is much cleaner in 2.6.
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html