Path: utzoo!attcan!uunet!husc6!ukma!nrl-cmf!ames!killer!rpp386!jfh
From: jfh@rpp386.Dallas.TX.US (The Beach Bum)
Newsgroups: comp.unix.wizards
Subject: Re: libraries
Summary: file system alternatives
Message-ID: <10242@rpp386.Dallas.TX.US>
Date: 21 Dec 88 22:13:04 GMT
References: <15080@mimsy.UUCP> <1278@nusdhub.UUCP>
Reply-To: jfh@rpp386.Dallas.TX.US (The Beach Bum)
Followup-To: poster
Organization: Big "D" Home for Wayward Hackers
Lines: 54

In article <1278@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>Wrong-O kid!  An archive library is a "File which contains the
>original contents of zero-or-more external sources, usually text or
>object files, which have been reduced to a single system object."

Please don't be pendantic about it.  The discussion was over using a
directory to archive object libraries, not as a general purpose file
archiver.

>A library directory you never scan would be useless. Ncest' Pa?
>[sic ;-)]

Also, don't use French if you can't spell it correctly.  N'est-ce pas?
We do not need to be impressed with your foreign language skills, and
Henry Spencer will no doubt include a reference to you in his next
.signature ;-)

>IF you would like to see an example of what a dog it would be to
>create/replace a symbol table run "expire -r -h -i" which will open
>every article once and create a history entry for it.

Weak analogy.  There are orders of magnitudes of difference between
the number of news articles on a system and the number of elements in
an archive file.

The limitation in the library directory approach is the file system,
which is not designed with an efficient file name lookup mechanism.
This is similiarly seen when reading news because of the high number
of file opens, etc.  File lookups display file system performance
of some hairy polynomial order.  This is aggrevated by the Version 7
file system peculairity of separating inode blocks and directory blocks
with large amounts of head motion.  [ Times the number of partitions or
drives which must be crossed - i.e., I mount both /usr and /usr/spool.
BIG head motion there. ]

Resolve the inefficiencies of the file system and the approach becomes
feasible.  Replace the current directory/inode approach with something
of a higher performance nature than library/archive accessing then
suddenly archive directories display higher performance.  Perhaps ISAM
using virtual directories?  Perhaps a filename/inode database of some
other nature?  Sorted directories and a binary search namei?  Any number
of implementation strategies exist to improve actual file system
behavior.

>p.s. You try being dislexic for a few years and then make comments
>about spelling.

I was unaware that the spell command didn't work on dyslexic computers?
[ =<:-) ]
-- 
John F. Haugh II                        +-Quote of the Week:-------------------
VoiceNet: (214) 250-3311   Data: -6272  |"Unix doesn't have bugs,
InterNet: jfh@rpp386.Dallas.TX.US       | Unix is a bug"
UucpNet : <backbone>!killer!rpp386!jfh  +--              -- author forgotten --