From owner-freebsd-current Sun Oct 10 13:58:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 1900915036; Sun, 10 Oct 1999 13:58:05 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id OAA06730; Sun, 10 Oct 1999 14:57:57 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA11530; Sun, 10 Oct 1999 14:57:55 -0600 Date: Sun, 10 Oct 1999 14:57:55 -0600 Message-Id: <199910102057.OAA11530@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Bruce Evans , freebsd-arch@FreeBSD.org, mckusick@mckusick.com, committers@FreeBSD.org, current@FreeBSD.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I Can't believe this email only produced TWO responses! > I would have thought that this wouldhav brought out the chainsaws! > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't > work? (the only responders got it via 'core') Interesting. It appears that somehow I got 'unsubscribed' from arch. Not sure why, but in May I was subscribed, but I'm no longer subscribed. Did everyone get unsubscribed when it went idle? (I'm not commenting on the content as I haven't done enough research to agree/disagree with anything yet.) Nate > > julian > > On Sat, 9 Oct 1999, Bruce Evans wrote: > > > > PHK has been moving steadily in this direction to remove as many > > > dependencies within the kernel on block devices as possible. > > > The question is, When did the decision to do so become official? > > > > Never. > > > > > I don't believe it has been a stated official decision yet and so in order > > > to put some clarity into the air over this I'd like to launch a PURELY > > > TECHNICAL discussion on the topic. > > > > > > Here are some starters. > > > > > > 1/ block device writes have to be synchrnous or the user doesn't get > > > write errors. > > > > Block devices should be implmented properly or the user doesn't get write > > errors. > > > > A proper implementation is quite close. Write errors should be reported > > on last-close and on fsync(). They already are as far as I can see, modulo > > the bugs that (in -current) VOP_FSYNC() = ffs_fsync() sometimes hangs > > instead of returning a write error and vinvalbuf() sometimes panics instead > > of returning a write error. The bugs are different and worse in RELENG_3. > > The bugs are different and more benign in RELENG_2_2 (write errors are > > ignored). Note that the bugs have very little to do with specfs. All > > specfs can reasonably do is kill the endless retries at a suitable time, > > probably after calling vinvalbuf() in last-close. > > > > > 1A/ if they are not synchronous, errors need to be coped with in some > > > other manner. > > > > Normal error handling suffices, modulo bugs. > > > > > 2/ People with old UNIX experience expect to be able to do unalligned > > > transfers on block devices. > > > 3/ DEVFS can cope just fine with block and char devices > > > (I include this because DEVFS has been used as an argument for > > > removing them) > > > > Correct. > > > > > 4/ Most of the block buffering code in the kernel will remain due to > > > the VM and VFS systems. > > > > Well, if the Nth rewrite of vm wants to drop support for buffers in vfs, > > then use of buffers for block devices shouldn't stop it. > > > > > 5/ New users don't tend to understand the rather strange distinctions > > > between BLK and CHR devices. Some people consider having both POLA and > > > > This is an argument for removing character (disk) devices, since most > > new users will be from Linux where block (disk) devices were the only > > ones available until recently. Block devices have always worked better > > in Linux. E.g., media change is detected for floppies, and buffers > > remain valid across last-close, until media change. The latter behaviour > > can be not what is wanted (extra ioctls are needed to discard the buffers), > > but it is often useful. > > > > > others consider having only one POLA. Linux had til just recently, > > > only BLK disk devices. They just aded CHR disk devices but I don't > > > know if they created a whole second calss of device to do so. (I doubt it) > > > 6/ It should be possible to make an overlay device (similar to the way > > > ccd works), that supplies buffered characteristics to a disk. This may > > > be a different minor number or a differnt major number.. but be a CHR > > > type device. > > > > This would involve needless duplicatication of half of the buffer cache > > implementation (maybe the simple half) unless the buffer cache goes away. > > > > Bruce > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message