Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!deccrl!news.crl.dec.com!shlump.nac.dec.com!decuac!hussar.dco.dec.com!mjr
From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Newsgroups: comp.unix.internals
Subject: Re: Ideas for changes to Unix filesystem
Message-ID: <1991Feb04.000126.11742@decuac.dec.com>
Date: 4 Feb 91 00:01:26 GMT
References: <1991Jan30.143326.16676@socs.uts.edu.au>
Organization: Digital Equipment Corp., Washington Ultrix Resource Center
Lines: 52

jeremy@socs.uts.edu.au (Jeremy Fitzhardinge) writes:

>1 - a flink(char *path, int fd) system call/operation.

	Part of the problem with such a system call is that it would
break a lot of fairly clean and elegant interfaces. Presently, you can
(for example) write code that ignores whether it is writing to a
tty, a socket, or a disk file. An flink() system call would break
that because you'd have to generate an error if someone tried to
flink() a socket to a filename. Sure, it'd be do-able, but there
would be lots of grotty special cases to deal with. The question then
becomes "why?" - actual cases where someone would want to do such a
thing are fairly rare, I believe - not worth the cost that would be
incurred. You'd also have the same problem that you'd get an error
if you tried to flink() across a device. In the cross-device case,
copying it back is far more portable.

>2 - insertion/deletion in the middle of a file without copying

	This is another fairly special case. I don't have any hard
statistics, but I suspect most file activity is sequential or random,
and a random sequential :) file wouldn't be used a whole lot. There
are a lot of cases where this would be very nice, and typically
such functionality is fairly easily added to an application via a
set of library routines that manipulates blocks in some form of
linked list. This is probably a good way to do it, since it won't
make the inodes bigger (which means that EVERY file will waste extra
space) - it's also just a simple issue of application support. If
I write my application with a library to handle file management,
I don't have to worry that it won't run on Joe Bob's UNIX which
hasn't got kernel support for chunked files. That counts for a
lot. Generally, it's better to put stuff in the application
layer unless it *HAS* to go into the kernel, or unless it will
somehow dramatically help all the applications running on that
kernel - without breaking portability. For example, implementing
Osterhout's log-based file system and getting a 10% write speed
up would be a bigger win for 95% of the applications on the system
than getting a 95% speedup for 10% of the applications.

>3 - limited sized files

	There are a lot of things that UNIX doesn't do that it
might be nice if it did - but a lot of those are because it'd be
unnecessarily complex or expensive to do them, and the return on
investment is fairly low. Fortunately, kernel hackers have been
one of the last bastions against the "let's just add this feature
because it'd look neet" crowd - otherwise UNIX would look like
X-window or GNUemacs.

mjr.
-- 
	Lutraphiles unite!