Date: Thu, 24 Oct 2002 00:08:10 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@FreeBSD.ORG Subject: Re: KVAless IO and buffer cache changes Message-ID: <47466.1035410890@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 23 Oct 2002 17:43:50 EDT." <20021023165651.W22147-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20021023165651.W22147-100000@mail.chesapeake.net>, Jeff Roberson wr ites: >A vectorized, address space tagged bio with queue points for delayed IO. Sold, as I just said, first ting after the next branch. >This will allow us to do IO to physical addresses. It would make bio look >more like UIO, but instead of iovecs we might want to try bus dma >segments. Sound right to me. >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. [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. 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. 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?47466.1035410890>