Re: Distributed storage.

On Monday 13 August 2007 02:18, Evgeniy Polyakov wrote:

On Mon, Aug 13, 2007 at 02:08:57AM -0700, Daniel Phillips 

(phillips@phunq.net) wrote:

quoted

quoted

But that idea fails as well, since reference counts and IO
completion are two completely seperate entities. So unless end IO
just happens to be the last user holding a reference to the bio,
you cannot free it.

That is not a problem.  When bio_put hits zero it calls ->endio
instead of the destructor.  The ->endio sees that the count is zero
and destroys the bio.

This is not a very good solution, since it requires all users of the
bios to know how to free it.

No, only the specific ->endio needs to know that, which is set by the 
bio owner, so this knowledge lies in exactly the right place.  A small 
handful of generic endios all with the same destructor are used nearly 
everywhere.

Right now it is hidden. 
And adds additional atomic check (although reading is quite fast) in
the end_io.

Actual endio happens once in the lifetime of the transfer, this read 
will be entirely lost in the noise.

And for what purpose? To eat 8 bytes on 64bit platform? 
This will not reduce its size noticebly, so the same number of bios
will be in the cache's page, so what is a gain? All this cleanups and
logic complicatins should be performed only if after size shring
increased number of bios can fit into cache's page, will it be done
after such cleanups?

Well, exactly,   My point from the beginning was that the size of struct 
bio is not even close to being a problem and adding a few bytes to it 
in the interest of doing the cleanest fix to a core kernel bug is just 
not a dominant issue.

I suppose that leaving out the word "bloated" and skipping straight to 
the "doesn't matter" proof would have saved some bandwidth.

Regards,

Daniel