Date: Mon, 20 Sep 1999 02:35:56 +0800 From: Peter Wemm <peter@netplex.com.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Matthew Jacob <mjacob@feral.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, dg@root.com, Greg Lehey <grog@lemis.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: User block device access (was: cvs commit: src/sys/miscfs/specfs spec_vnops.c src/sys/sys vnode.h src/sys/kern vfs_subr.c) Message-ID: <19990919183556.802C81CA7@overcee.netplex.com.au> In-Reply-To: Your message of "Sun, 19 Sep 1999 11:01:12 MST." <199909191801.LAA73219@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
>
> :> :to fix the block dev interface is not a very hard problem.
> :> :
> :> :--
> :> :Poul-Henning Kamp FreeBSD coreteam member
> :>
> :> The buffered block device is not slow, I don't know where you get
> :> that idea from. It is, in fact, just about as fast as you can get and
> :> still cache the data, which is to say somewhat faster then normal file
> :> access would be. The cache is flushed on every open of the device
> :> which may be causing your confusion. There is no overhead beyond the
> :> normal overhead associated with caching a file.
> :
> :It can be slow for reads, but fast for writes if you have a good
> :clustering mechanism.
[..]
> You could characterize this as 'slightly slower' but you could not
> characterize this as 'slow'. The slight loss in performance is simply
> due to the smaller block size (2K vs 8K), the fact that we aren't VMIO'in
g
> the block device, and the shorter read-ahead. Except for the lack of
> VMIO these tend to effect only the sequential access case so I've never
> been particularly worried about it. I suppose it could be 'fixed'. I
> don't think it's a big deal.
I personally like the idea of doing buffered IO via the VM system. After
all, the device has a backing vnode, and as you pointed out, using the VM
system is only slightly slower than using the bdev and the bio cache
directly. It has a number of advantages, namely simplifying the caching
aspects of everything a fair bit since there are no longer coherency
measures between bio and vm to maintain as the bio layer ends up with no
caching at all. Opening and accessing a block (buffered) device would
still look exactly the same to the user, but would be going via a pager
rather than bread/bwrite and the hassles that causes. struct buf then
becomes just a plain IO request for the device interface. Of course, this
is easier said than done so I'll shut up now. :-)
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990919183556.802C81CA7>