On Mon, 20 Nov 2000 21:29:25 -0200, Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>
>On Mon, 20 Nov 2000, Chaitanya Tumuluri wrote:
>> On Sun, 19 Nov 2000 17:24:57 -0200, Marcelo Tosatti
>> Thus, I'd agree with your suggestions below for the 2.5 timeframe. Can it
>> 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
>> kiobuf-I/O code path starts to do request merging in the elevator. See 2.
>Are you sure the elevator code for kiobuf and buffer heads will be the
No, not the same. But sufficiently similar that we should think in terms of
and reducing the footprint of the changes needed.
>> With your changes above, the LVM/RAID codepath is *forced* to make the
>> while the current codepath doesn't preclude LVM/RAID from having these
>> functions, but doesn't _require_ the separation either. For now, I think
>> 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
many changes currently, is that Eric Youngdale is thinking in terms of a major
to the block-queueing layer (including getting rid of the old scsi
and the drivers that break with it!). So, perhaps, we should revisit this
when 2.5 does open up and then rework the queueing layer as you suggest along
else that wants to improve it! :^)