Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!boulder!pikes!udenva!isis!scicom!zebra!vern
From: vern@zebra.UUCP (Vernon C. Hoxie)
Newsgroups: comp.unix.wizards
Subject: Must UNIX be a memory hog?
Keywords: TZ, uucp LCK... files
Message-ID: <159@zebra.UUCP>
Date: 9 May 89 10:29:28 GMT
Organization: Alpha Science Computer Networks, Denver, Colo.
Lines: 41


Gentlemen:
	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.

	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.

	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?

	In the case of 'TZ', a struct could have been developed but
then, the code necessary to change this parameter might well be greater
than the 1024 bytes wasted by the present method.  Of course, there is a
working equivalent to the information obtained from the 'TZ' file which
already has the supporting code.

	The 'LCK...xxx' files contain the PID of the process which
opened them so that janitorial type processes could determine if the
need for the lock still exists.  Should a process die without removing
the 'LCK...xxx', the janitor sweeps them away.

	My basic question is: Is this good programming form?  Should
not these processes been implemented with something of the nature
of 'semaphores' or 'signals' or some other system level concept?  A
conception which will accomplish the desired result without hogging so
much memory.

	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.

-- 
Vernon C. Hoxie		       {ncar,nbires,boulder,isis}!scicom!zebra!vern
3975 W. 29th Ave.					voice: 303-477-1780
Denver, Colo., 80212					 uucp: 303-455-2670