Date: Wed, 23 Oct 2002 18:18:14 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: arch@FreeBSD.ORG Subject: Re: KVAless IO and buffer cache changes Message-ID: <20021023181051.A22147-100000@mail.chesapeake.net> In-Reply-To: <47466.1035410890@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Oct 2002, Poul-Henning Kamp wrote: > In message <20021023165651.W22147-100000@mail.chesapeake.net>, Jeff Roberson wr > ites: > > >In addition to this, the delayed write layer should be a small > >module that deals only with bios. This would require making bio a real > >object to support the many users. > > It will take some convincing before you get me in on this one: bio > is not and should not become an object, it is a communication > protocol for disk-like I/O. > Well, the motivation for this is that we have many differnt memory containers that all want to do IO. For example, we have memory backed bufs, anonymous bufs, and the proposed vnode pager backed bufs. All of these things want delayed IO and they all will need a bio. The delayed IO bits could be kept seperate from the bio structure though. This would make it a very thin layer above bio that is not visible to the lower layers. I understand the aversion to the buf/bio tangle. > > [Various stuff which sounds right to me] > > >For the latter two they > >would have an embedded bio that would use the delayed write interface. > > This is related to the above. I think we should loose the buf-embedded > bio as soon as we can. Yes, definitely. That is a component of my approach. > > The new_bio/clone_bio/delete_bio from GEOM should probably be pulled > out to a more generic place and twisted to use UMA. > > >I have many pages of design notes. If there is enough interest I could > >write up a formal design proposal. > > That would be very welcome! > > Just do me the favour of thinking of struct bio as a way to bundle > up the parameters of an I/O request and nothing more. Duly noted. > > If you need a true object for mitigating access and keeping state, > struct bio isn't the right place to do it, because GEOM and device > drivers are not interested in that state, and they may create > and spawn new bios using opaque methods and we will have no way > to make sure the right, if even any, attributes get correctly > mapped over. > > There _will_ be a VM interaction from GEOM/drivers because various > GEOM classes or device drivers may need either physical or mapped > access to the vector before/after access or modifications. > Yes, I think this could be achieved through private, short term mapping functions for physical IO. It would be like pager bufs but of a much more limited use. Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021023181051.A22147-100000>