Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lanl!cmcl2!adm!xadmx!rroba.DlosLV@xerox.com
From: rroba.DlosLV@xerox.com
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you want in the GNU OS
Message-ID: <19963@adm.BRL.MIL>
Date: 10 Jun 89 06:29:06 GMT
Sender: news@adm.BRL.MIL
Lines: 63

In response to an earlier posting, in which I said:
> Three things that should not be in an efficient OS:
>	1) virtual memory
>	2) symbolic links
>	3) long file names (BSD directories)
Bob Cherry says, "This list is extremely application dependant. "   I
agree.  My purpose in posting these comments  is to point out that what is
appropriate for some applications is poison to others.

Bob goes on to say, "Virtual Memory:  VMem is quite useful especially in
CAD tools and high volume/resolution graphics.  On multi-user systems it
becomes unrealistic to keep gigabytes of RAM around in order to perform
high volume graphics. "   Again, I agree.  My own background has been
principally in embedded systems, in which 1) data throughput is the measure
of success, and 2) system RAM requirements are pre-determinable.  In this
environment, VM is not needed and imposes an execution cost that I would
rather not pay.

Then he says, "Eliminating VMem eliminates the ability to operate a wide
range of applications and/or programming environments."  This is a good
point.  But, in the environments that I work in, the applications that will
be run on a particular system are known and fixed; so that this is not a
concern.  Throughput, however, is still a concern.
  
"Symbolic Links:  These links are extremely useful when a third party
application requires that it be run from a specific directory.  If the
particular directory is in its own disk partition and if that partition
does not have adequate free space to install or operate, a link may be used
to map the actual directory to the desired directory."  This is a
description of a situation  (partitioned drive) that was created by either
the user or the (auto-installation program of the) OS distributor (i.e. Sun
Microsystems).  On multi-user systems, partitioning a drive facilitates the
creation of secure backups from online file systems (because the partitions
can be individually umounted and dumped).  Partitioning a drive, however,
always has a negative impact on file system throughput (through increased
seek time), and should not be done on single-user or embedded systems.  The
exception is single-drive VM systems, in which the swap device should be
located somewhere in the middle of the drive, in order to minimize the
impact of VM on file system performance.  But, even here, my opinion is
that VM systems should never be single-drive.

Next, Bob echoes my own opinions, "Inode mapping is more efficient and Unix
offers the ability to make both hard and soft links.  Hard links do not
impact disk access as much as soft links do."  But then, he says, "If a
user doesn't make symbolic links to his environment, there should be no
impact on the operation of the OS."  The problem is that most symbolic
links are not created by the user (God knows I wouldn't make one, if I had
a choice), but are distributed with the OS.  Although in the GNU case,  if
the system is distributed as source without any assumptions about file
system partitioning, my arguments will be moot; this is a major cause of
poor file system performance in SunOS (for the 386i).

"Long Filenames: I do not see any impact on an OS by allowing long names. "
My objection is not against long filenames, in general, as much as it is
against the structure of BSD directories in particular.  The complicated
system of counts and offsets that must be traversed in a BSD directory must
consume much more cpu time than the relatively simple structure of AT&T's
directories (I am aware that AT&T, sadly,  will adopt BSD's directory
structure in the 'unified UNIX').  I am not concerned about the time
required to extract a long name from a BSD directory, as opposed to
extracting a short name from a BSD directory.  I am concerned about the
time that it takes to extract the inode number of the nth entry in a BSD
directory.