Date: Sun, 19 Sep 1999 12:43:42 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: 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: <Pine.BSF.4.05.9909191238090.42176-100000@semuta.feral.com> In-Reply-To: <199909191801.LAA73219@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > :> :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. > > Negative, it will not be slow for reads. The block device issues > read-aheads based on a similar heuristic that normal file reads use, > but limited to a single block. If the data is not in the cache a second > memory copy is incurred, but this is also true of a file read. Point taken, but relative to a raw read it may be slowER, and also may involve interference effects or even unintended side effects (in case of tape, e.g.) with the read ahead. This is like the mail from Poul, though. We should not be arguing over which is better or which has the error policy characteristics we want. We should decide whether or not there is a valid case for retaining user level block access reads and go from there. I believe that at the very least a simple common read-modify-write of a non-sector sized quantity is alone enough to justify the retention (if it causes problems withperformance, tell people to not use it). Can we decide this and move on to more important (IMO) IO/OS/VM topics like when we're gonna have an adult OS sized raw I/O limit and a reasonable tunable NCARGS and tunable clustering and readahead policies? -matt 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?Pine.BSF.4.05.9909191238090.42176-100000>