Date: Wed, 13 Oct 1999 23:44:52 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mckusick@flamingo.McKusick.COM (Kirk McKusick) Cc: julian@whistle.com, freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. Message-ID: <199910132344.QAA24624@usr01.primenet.com> In-Reply-To: <199910131738.KAA18428@flamingo.McKusick.COM> from "Kirk McKusick" at Oct 13, 99 10:38:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
> The question is, "How much code will it clear up?" > The opinions differ. > And, just because we can't point out one at the moment doesn't > mean that there aren't any. > > If no one on the list can think of any use, I doubt that there is one. > Just because there might some day be a use is not enough reason to have > an interface. BSD has stayed lean and mean (relative to the commercial > Unix varients) by actively throwing out decrepit interfaces. If we revert > to the vendor `keep every interface that we ever put in the kernel for > fear of upsetting some legacy application' we will end up with a bloated, > hard to maintain, hard to evolve system. We have pitched far more heavily > used interfaces than block devices and been better for it. I agree with this sentiment. However, this seems to argue for pitching character devices, since character devices have the restriction that they must be accessed on block boundaries in block size increments, whereas block devices have no such restriction. When choosing between interfaces, it seems to me that keeping the one with the least restrictions, and pitching the one with the most, would be the more correct approach. I really object to having to modify user space code to know about having to access things on block boundaries, and having to cache a blocks worth of data (dependant on whatever the native block size of the underlying device happens to be) in order to update regions. It makes little sense to do this in many user space programs, as opposed to making the opacity of the blocking a kernel function. With regard to unnecessary block buffering occorruing in the kernel, two candidates ripe for a bullet in the head are directory entry blocks, and the inode hash. The inode hash could be easily eliminated by not breaking the vnode/inode association arbitrarily (perhaps by yielding ownership of vnodes which incorporate inodes at the end of their structure to the FS containing the inodes). The directory entry block code is a historical wart, which has the effect of preventing us from going forward with things like btree based directories, native Unicode support for 256 character filenames (_NOT_ UTF-8 encoded: that would require up to 1280 octets for a worst-case encoding, whereas 16 bit fixed characters require only a maximum of 512 bytes -- but leave no room for directory metadata other than the file name, if limited to 512 byte blocks), multiple namespaces (needed to optimize Samba), ACL's, extended attributes, etc.. Both of these issues are roadblocks to progress... unlike block devices, which may be ugly in some people's eyes. > There is also the issue of Posix standards etc. > is a 'Unix' supposed to have two kinds of devices? > the standards certainly define block and character devices. > might a process use block devices as a mething of allowing > caching between multiple co-operating processes? > > Julian > > Posix defines that there are two types. It says absolutely nothing > about the semantics of the two types. It does not require that you > have both types, merely that you be able to report them if they are > there. As for maintaining caching between processes, we already have > two ways of doing that. FIFO's (a descriptor I/O based method) and > shared memory (obtained via mmap). We do not need another descriptor > based method. > > Kirk McKusick Julian's example of cooperating processes is flawed, since that is an issue for the coherency model to deal with, but his reasoning is not; POSIX states (from the "Go Solo 2" CDROM): character special file A file that refers to a device. One specific type of character special file is a terminal device file, whose access is defined in "General Terminal Interface" in (XBD). ... block special file A file that refers to a device. A block special file is normally distinguished from a character special file by providing access to the device in a manner such that the hardware characteristics of the device are not visible. The standards (POSIX, et. al.) _do_ require both types of special files. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199910132344.QAA24624>