On Mon, 20 Nov 2000, Chaitanya Tumuluri wrote:
>
> On Sun, 19 Nov 2000 17:24:57 -0200, Marcelo Tosatti
> <marcelo@xxxxxxxxxxxxxxxx> wrote:
> >
> >Chait, Jens, Martin,
> >
> Hi Marcelo,
>
> Seeing as how no-one's replied as yet; lemme take a quick stab at a response.
>
> >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.
> >
>
> That was the way it was originally implemented in the test1 thro' test5 XFS
> trees
> with: ll_rw_kio() calling __make_kio_request()
> a la: ll_rw_block() calling __make_request()
> Then things changed from test8 on, where generic_make_request() was
> introduced to
> accomodate stackable drivers, which broke things severely for the kiobuf I/O
> path.
>
> >This way the code gets cleaner, more simple, and independant from
> >each other.
>
> Yes, that was the original intent of the separate codepaths. However, there
> were
> three comments made (by Alan Cox, Eric Youngdale, Stephen Tweedie among
> others),
> when I had originally submitted the kiobuf I/O patch to the kernel mailing
> lists:
>
> 1. develop code only as a prototype/proof-of-concept for the 2.4
> timeframe,
> 2. reuse code as far as possible,
> 3. keep the footprint of the changes small (for 2.4).
>
> Thus, I'd agree with your suggestions below for the 2.5 timeframe. Can it wait
> till then, or do you see a need for it in the RAID implementation?
No, its not needed.
Currently I'm doing raid1_make_request() in a easy way to port it to when
we have the codepath separation:
static int bh_raid1_make_request(mddev_t *mddev, int rw, struct buffer_head *bh
...)
and
static int kio_raid1_make_request(mddev_t *mddev, int rw, struct kiobuf
*kiobuf...)
The main raid1_make_request is basically this:
if(bh)
return bh_raid1_make_request(mddev, rw, bh, dev, sector, count,
r1_bh);
else if (kiobuf)
return kio_raid1_make_request(mddev, rw, kiobuf, dev, sector,
count, r1_bh);
> As for LVM, I think it'd be a fairly simple to rework the 2.4 code for
> the 2.5 kernel when the split in the codepaths becomes more apparent.
> mkp/axboe ?
>
> >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.
>
> This would certainly entail touching/modifying a whole bunch of drivers in the
> kernel source (since you are changing an API). See 3. above.
>
> >- split __make_request into ll_kio_make_request and ll_bh_make_request (or
> >whatever better name for the functions).
>
> This results in fairly large amounts of code duplication, especially when the
> kiobuf-I/O code path starts to do request merging in the elevator. See 2.
> above.
Are you sure the elevator code for kiobuf and buffer heads will be the
same ?
> To the extent possible, the current implementation tries to reuse code common
> to
> the bh and kiobuf codepath. It deviates only in initializing:
> * req->buffer, req->current_nr_sectors, req->nr_segments
> * req->kiobuf, req->bh, req->bhtail
> via two separate functions: __blk_init_req_kio() and __blk_init_req_bh()
>
> So, in a sense, this separation is there already.
>
> >- 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.
>
> With your changes above, the LVM/RAID codepath is *forced* to make the
> separation,
> while the current codepath doesn't preclude LVM/RAID from having these
> separate
> functions, but doesn't _require_ the separation either. For now, I think its
> better to keep the options open, no?
The reason I want to force codepath separation in SGI XFS tree is to make
it ready for 2.5 merge without pain.
> >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).
>
> Cool! How is it working out?
Working perfectly except when reconstruction is going on.
hopefully I'll the bug tomorrow.
|