[Top] [All Lists]

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

To: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>
Subject: Re: [RFC] split kiobuf/buffer-head IO code Re: xfs file system
From: Chaitanya Tumuluri <chait@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 20 Nov 2000 16:05:10 -0500
Cc: linux-xfs@xxxxxxxxxxx, axboe@xxxxxxx, mkp@xxxxxxxxxxxxx
In-reply-to: Your message of "Mon, 20 Nov 2000 21:29:25 -0200." <Pine.LNX.4.21.0011202120270.6397-100000@xxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
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 
<marcelo@xxxxxxxxxxxxxxxx> wrot
   >> 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
   >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 
   >> 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 
error-handling code
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 
with everyone
else that wants to improve it! :^)

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