Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!uflorida!codas!mtune!mtunx!whuts!homxb!antique!cjp
From: cjp@antique.UUCP (Charles Poirier)
Newsgroups: comp.sys.amiga
Subject: Re: Ban the Cloud! (plus sugg. for Workbench)
Message-ID: <2105@antique.UUCP>
Date: 10 Mar 88 01:01:04 GMT
References: <5328@swan.ulowell.edu> <3440@cbmvax.UUCP>
Reply-To: cjp@vax135.UUCP (Charles Poirier)
Organization: AT&T Bell Labs, Holmdel, NJ
Lines: 67

In article <3440@cbmvax.UUCP> steveb@cbmvax.UUCP (Steve Beats) writes:
>In article <5328@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes:
>>
>>Why not do it RIGHT and put the list in the directory header, so users
>>can't muck with it?  Sure it means a ROM change, but since FFS is
>>....
>I'm not going to get into a religious war here, but just how do you propose
>to fit a theoretically infinite number of filenames into one directory header?
>If you say "use extension blocks" then I say "file headers ARE extension
>blocks".

Pardon me?  The big problem is that in the current filesystem, the file
names are scattered all over the disk.  Packing the filenames one per
block is about the worst one can do in this regard.  Packing as many
filenames as will fit into each block, using extension blocks as
needed, is about the best one can do.  Are you implying these schemes
are equivalent?  The fact that they both use extension blocks seems
quite irrelevant.

>If you start putting lists of filenames onto the disk, you're gonna have to scan
>those lists, and boy is it going to slow down.

The time needed to scan a block of filenames is dominated by the time
needed to get that block into memory.  Scanning will be fast enough.
Besides, you do not need to scan that list for every type of operation.

Why not this:  Keep the current hashing scheme, AND a compact filename-
list scheme.  The list form would only be scanned in two cases:  when
examining all filenames, and when deleting files.  The former case is a
big win, and the latter is not so bad.  For deleting a file, you have
to rewrite the extension block containing the deleted name.  For
creating a new file, you hash to see if the filename exists -- if not,
just slap it onto the end of the filename list.  In exchange for the
trouble of maintaining filenames in two places, you get fast access to
known files AND unknown filenames -- a real big win.

>I'd like to take this
>oppurtunity to state that the Amiga filing system, as it stands now, is a
>really well thought out item, kudos to Tim King on that one.
>However, I believe it fell down a little on the implementation, BCPL and
>such, rasberries to Tim for that :-)

Accessing files *by name* works great.  But since Tim King stuck us
with the "directory search" problem, he gets no kudos from me.

BCPL is not the main problem.  The problem, from the users' point of
view, is that opening a window takes forever; doing a list takes
forever; doing a dir takes forever; doing a pattern match takes
forever.  There are things like filename-completion that we can't even
think about adding, because of the stupid directory design.

>FFS was re-written to address the shortcomings of the
>old system and I think it does this quite well.

I obviously don't know how FFS works, especially if and when it is
applied to floppies.  But you now have me worried.  I hope it's not a
rehash of what was done for 1.2, just tweaking where on the disk the
same old blocks are located.  If the filenames are still stored
one-per-block, they will end up all over the disk, and directory
searching just isn't going to be fast enough.

>	Steve

-- 
	Charles Poirier   (decvax,ihnp4,attmail)!vax135!cjp

   "Docking complete...       Docking complete...       Docking complete..."