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>