On Mon, 6 Nov 2000, Chaitanya Tumuluri wrote:
> 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
Right now, I think the following should be done:
- split request_queue_t->make_request_fn into kio_make_request_fn and
- 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
- 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
This way, LVM and RAID should have their own kio_make_request and
bh_make_request separate functions.
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