🚀 go-pugleaf

In article <1348@cuenews.UUCP> andrew@cuenews.UUCP (Andrew Folkins) writes:
>
>Now, under the FFS, I can't figure out what's going on.  It's
>definitely *not* the same, as printing the hash table values while
>'list'ing produces something like:
>
>      sector  track sector head hash  filename
>       74375    364     17    3   52  list
>       74868    367     00    0   59  list.lnk
>       75259    368     17    5   47  list.c
>       75274    368     32    5   59  list.o
>       77000    377     24    2    0  skeleton.c
>       77002    377     26    2   33  textmap.c
>       77004    377     28    2   51  isqrt.c
>       77006    377     30    2   54  textmap
>       77008    377     32    2    5  textmap.lnk
>       77178    378     32    1   52  conpackets.c
>       etc.

Thank you for exploring these details.

Please correct me if I'm wrong, but this seems to be a sort of
elevator seeking already. Everytime the algorithm finds a new
block number, it does not go to that sector immediately but puts
it into a sorted list of sectors yet to search for. Thus you can
avoid many of the head movements necessary with the older, dumber
mechanism. If I understand it correctly, there may still arise
problems when the blocks are spread too wildly, but also then it
boils down to only a few passes of the head across the disk.

(This is all only speculation, I don't know the source, but had
thought about this one already long for myself, but didn't get
time for it. So I'm very pleased that they've done it already
at West Chester, thanks.)

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk