Date: Sun, 19 Sep 1999 10:15:47 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: 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: <199909191715.KAA72822@apollo.backplane.com> References: <15064.937728650@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
: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.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199909191715.KAA72822>