Must UNIX be a memory hog?

[Guy Harris]

>	Since first becoming acquainted with the UNIX system, I have
>curious about the use of entire sectors of memory for such trivial
>entries as 'TZ' and 'LCK..xxx' files.

I presume by "memory" here you mean disk memory rather than main memory.

>	In the case of 'TZ', this file will have at maximum 10 bytes but
>it requires 1024 bytes of memory on most systems.  Multiplied by the
>number of UNIX systems in operation, that is a whale of a lot of wasted
>memory.  This could be one of the most expensive constants in the
>computing world.

Uhh, to what are you referring, here?  The references to "files" makes
it sound like you're referring to the time zone files used by the
"Arthur Olson" time zone code, but they're not "at maximum 10 bytes";
they're typically more like 750 bytes or so.  110592 bytes are taken up
by the "/usr/share/lib/zoneinfo" directory on the system here, which
isn't a heck fo a lot.

The "10 bytes" part is a bit mysterious, then; are you referring to
space on disk, or what?  In systems not using the Olson code, time zone
information is stored in a file only in those files that set the TZ
environment variable.  This is generally either:

	"/etc/profile" - which does a lot more than just set "TZ",
	and is generally longer than 10 bytes; what's more, there's
	only one "/etc/profile" file, so *relative to the number of
	files on the system* it's a drop in the bucket.

or
	"/etc/TIMEZONE" - which only sets a few environment variables,
	at most, but again there's only one of them.

If you really want to get fanatical about wasted disk space, worry about
the "true" command; it doesn't need to contain any data, but on more
recent versions of System V, for example, it contains an AT&T copyright
notice (right, they've copyrighted the null sequence of bytes; give me a
break).  Multiply *that* by the number of UNIX systems with that style
of "true" command, and just *imagine* what a *huge* chunk of the GNPs of
the world's nations are being *wasted* on that! :-) :-) :-) :-) :-)

>	The 'LCK..xxx' files used by uucp were intended to last on disk
>for only a short interval.  Never the less, sufficient memory must be
>available for when an external connection is made.  In the case of the
>3b1, permanent 'LCK...ph0' are in existence whenever the telephone
>controller is placed in the VOICE condition.
>
>	Is there not some other mechanism by which the functionality of
>these sparse files is accomplished but require much less storage space?

No.  Think of how little storage space they actually require; it's
simply not *worth* worrying about the disk space they take up.  On a
10MB disk, say, with one "/etc/TIMEZONE" file and 10 "LCK.." files,
that's 11 1KB files, or 11KB.  1% of 10MB is 100KB; you're talking about
.1% here - a drop in the bucket - and lots of disks are considerably
larger than 10MB these days.

>	While I have your attention, isn't a great deal of disk capacity
>wasted with directories that don't shrink?  As the number entries in a
>directory grows, additional disk blocks are assigned to the directory. 
>But when number entries in a directory is reduced, the number of blocks
>assigned to that directory remains at the high water mark.

Yeah, but unless the directory gets *very* big for a brief period of
time, and usually stays considerably below that size, it won't save
much.  4.3BSD will shrink directories, but I think the main win here may
be for directories like the UUCP spool directory when a big burst of
UUCP work comes in and then leaves - and even there I suspect the real
win of shrinking the directory is the reduction in time to search the
directory, not in disk space.