On Mon, 20 Nov 2000 21:29:25 -0200, Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>
wrote:
>On Mon, 20 Nov 2000, Chaitanya Tumuluri wrote:
>
>>
>> On Sun, 19 Nov 2000 17:24:57 -0200, Marcelo Tosatti
<marcelo@xxxxxxxxxxxxxxxx> wrot
>>e:
>>
>> 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:
>
> < Stuff Deleted >
>
Sweet! That should work.
>> 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 ?
No, not the same. But sufficiently similar that we should think in terms of
code reuse
and reducing the footprint of the changes needed.
>> 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.
>
The other reason (they seem to multiply with every email!) I don't want to make
too
many changes currently, is that Eric Youngdale is thinking in terms of a major
rewrite
to the block-queueing layer (including getting rid of the old scsi
error-handling code
and the drivers that break with it!). So, perhaps, we should revisit this
discussion
when 2.5 does open up and then rework the queueing layer as you suggest along
with everyone
else that wants to improve it! :^)
Cheers,
-Chait.
|