xfs
[Top] [All Lists]

[RFC] split kiobuf/buffer-head IO code Re: xfs file system

To: Chaitanya Tumuluri <chait@xxxxxxxxxxxxxxxxxxxx>
Subject: [RFC] split kiobuf/buffer-head IO code Re: xfs file system
From: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>
Date: Sun, 19 Nov 2000 17:24:57 -0200 (BRST)
Cc: linux-xfs@xxxxxxxxxxx, axboe@xxxxxxx, mkp@xxxxxxxxxxxxx
In-reply-to: <200011061445.JAA20862@getafix.engr.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Mon, 6 Nov 2000, Chaitanya Tumuluri wrote:

<snip>

> Again, in principle yes, you are right. However, the only major users of
> kiobuf I/O to date (raw I/O and XFS) already have their own compat. 
> codepaths. So, its not a burning issue to be addressed...as much as say
> someone stepping forward to work on the `md' driver :^)

Chait, Jens, Martin, 

Currently, generic_make_request() function and the per request queue
make_request_fn() operation implement buffer-head and kiobuf based IO.

IMHO the block layer should handle different IO "methods" (kiobuf and
buffer-head) with different code.

This way the code gets cleaner, more simple, and independant from
each other.

Right now, I think the following should be done: 

- split request_queue_t->make_request_fn into kio_make_request_fn and
bh_make_request_fn.

- Add a flag to be passed in blk_init_queue to inform if the caller
supports kiobuf based IO.  If the flag is on, set req->kio_make_request_fn
to __kio_make_request.
 
- split __make_request into ll_kio_make_request and ll_bh_make_request (or
whatever better name for the functions).

- split generic_make_request into kio_make_request and bh_make_request.
ll_rw_block should use bh_make_request and ll_rw_kio should use
kio_make_request.

This way, LVM and RAID should have their own kio_make_request and
bh_make_request separate functions.


Comments? 

I'm working on RAID1 code. I'm running dbench on a kiobuf mounted XFS
filesystem over a raid1 array with 2 SCSI partitions for some time now
(the code is not complete yet, though, and I want to solve the issue
discussed above).



<Prev in Thread] Current Thread [Next in Thread>