From owner-cvs-all Sun Sep 19 11:36:27 1999 Delivered-To: cvs-all@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id EEDDA158BA; Sun, 19 Sep 1999 11:35:57 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 802C81CA7; Mon, 20 Sep 1999 02:35:56 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: Matthew Jacob , Poul-Henning Kamp , dg@root.com, Greg Lehey , 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) In-reply-to: Your message of "Sun, 19 Sep 1999 11:01:12 MST." <199909191801.LAA73219@apollo.backplane.com> Date: Mon, 20 Sep 1999 02:35:56 +0800 From: Peter Wemm Message-Id: <19990919183556.802C81CA7@overcee.netplex.com.au> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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