Date: Sat, 9 Oct 1999 17:24:43 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@whistle.com> Cc: arch@freebsd.org, mckusick@mckusick.com, core@freebsd.org Subject: Re: The eventual fate of BLOCK devices. Message-ID: <Pine.BSF.4.10.9910091626360.2053-100000@alphplex.bde.org> In-Reply-To: <Pine.BSF.4.10.9910081840300.8009-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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-arch" 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.10.9910091626360.2053-100000>