From owner-cvs-all Sun Sep 19 10:23:22 1999 Delivered-To: cvs-all@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0348114CD3; Sun, 19 Sep 1999 10:23:17 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA31805; Sun, 19 Sep 1999 10:21:15 -0700 Date: Sun, 19 Sep 1999 10:22:50 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matthew Dillon Cc: 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: <199909191715.KAA72822@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > :My position is a little bit more flexible: I don't care which of > :the two interfaces we retain, as long as we only have one and as > :long as it isn't buggy (ie: it should return write errors). > : > :The argument for the block device is that it *is* more "unix feel" to > :be able to read and write at any byte and with any length. > : > :IFF we want to maintain the block interface, we need to fix the error > :return for the write case, but we also need to do a significant amount > :of work speeding it up. It currently is an order of magnitude slower > :than the char interface (remember to measure consumed CPU time, not > :wall-clock time). > : > :For anyone with a second disk or floppy drive in their system, attempting > :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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message