🚀 go-pugleaf

in article <88.filbo@gorn.santa-cruz.ca.us>, filbo@gorn.santa-cruz.ca.us (Bela Lubkin) says:
> Xref: cbmvax comp.sys.amiga.tech:9127 comp.sys.amiga:47011
> X-Claimer: I >am< R Pentomino!

> In article <832@lpami.wimsey.bc.ca> Larry Phillips writes:
>>The big advantage of the Amiga filing
>      ^^^^^^^^^^^^^
>>system is that a fully known filename is found VERY quickly. The reason for
>>this is that filenames are hashed into tables in the directory blocks, and can
>>be found within a (relatively) few seeks

> Oh, come ois and always has been bogus.  Even MS-DOS
> does far better than AmigaDOS in this area.  

Huh? Have you actually _used_ an MS-DOS system with paths set up similar to
the way an Amiga normally is? I have about 10x as many commands on my Amiga
path as on my MS-DOS path (AT Bridge Card).  There's a noticable wait for
any path search on the MS-DOS side.  There isn't on the Amiga.  That's what
I consider the bottom line.  But onward... 

> In the case of a known filename, MS-DOS reads the directory (which is effectively 
> a single small binary file),

Actually several binary files, since the directory very often (in fact, I
can think of very few counterexamples in actual use) has far more than 16
files. 

> Since each MS-DOS directory entry is 32 bytes, and a sector is 512 bytes, 16 
> entries fit in a sector; it must read (n/16) sectors to find a file..

So we'd have to read 9 sectors, worst case, to get an arbitrary file in my
C: directory of 132 files.  And perform up to 131 string comparisons.  The
midpoint would be 4 sectors and 65 string comparisons. 

On the Amiga, I'd have to read at least 2 sectors, the directory and the
file block.  I'd have to do one longword comparison to check for a hash
chain collision, and a string compare and possible sector read for each
hash chain entry until I find the file.  For my 132 entry directory,
there's likely to be one hash chain for each entry based on the hashtable
size of 72, so the average file would be found in no more than 3 sector
reads, a string comparison, and 2 longword comparisons.  If there were 4
hash collisions in any hash table entry, that would grow to a worst case of
5 sector reads, 4 string comparisons, and 5 longword comparisons. 

> Those sectors would almost always be physically contiguous.  

On an empty hard disk, sure.  But even then, you can't have it both ways. 
If your file is contiguous with the directory header, and you a bunch of
new stuff to that directory, something's not contiguous anymore.  Either
you have to uproot all the files or you're running all over the place to
collect those directory blocks. 

> Compare this to AmigaDOS, which must read an arbitrary number of sectors (often 1, 
> but sometimes more), are virtually guaranteed to be all over the disk.  

No they're not.  Have you ever actually looked at how the file system (FFS
especially) allocates things on the disk? I have, extensively.  Try running
DiskSalv over your hard disk sometime; things are nicely grouped.  And
also, no matter how badly fragged you get, hash collisions are linked in
sorted order, so you never jump all over the place, as you imply, to find a
named file. 

> Then compare wildcard operations.  MS-DOS must still read the entire directory, which is 
> still only a few (probably contiguous) sectors.  

Here MS-DOS would read 9 files for my C: directory, AmigaDOS would read
133.  That's a definite loss to AmigaDOS, even though it took much less time
to load the directory program in the first place (I'm talking real life
here; I refuse to use the built-in Dir command under MS-DOS, so I use a 
UNIX-alike LS which must be loaded from disk, same as the Amiga command).

> Amiread bone sector for each file in the directory, probably scattered all 
> over the disk.  I don't like this tradeoff in the least.

Again, the Amiga files aren't scattered all over the disk.  Do you really
think they just allocate things at random.  Sure, the disk would support
blocks scattered all over, just as any filesystem that doesn't choke when
nearing full would have to do.  But even on my 70% full 80 meg disk, I don't 
see any problems like those you seem to believe in.

The other thing you get from the Amiga FFS (even better under SFS) is ease
of reconstruction.  You can completely rebuild the entire disk structure
even if every directory in the system were destroyed.  There's no way to
lose more than one file with a single damaged block, and actually you'd
only lose part of that file in many cases (if you destroy the file block
header).  Under SFS, there's no way to lose any more than 1 block in a
file with a randomly damaged sector.  You've already told me I can put a
serious hurtin' on 16 files with one random sector blasted away.  What
happens if I destory the root directory?

> The other argument I've heard for AmigaDOS' directory structure is "unlimited
> directory size", which is also bogus.  Nothing limits any directory under
> MS-DOS, >except< the root directory.  

Nothing limits the size of an FFS directory execpt the hard disk.  I think
we win here.  Microsoft made lots of bad decisions for MS-DOS, but the worst
was that they didn't have the forsight back then to build a system that let
these things be fixed later very compatibly.  You can yell all day about What
Could Have Been, but most folks are far more concerned with What Actually Is
and What Yet Will Be.  Though they say that the 35 meg, or whatever, limit on 
hard disks is going Real Soon Now.

Good thing about AmigaDOS is that you can pick the filesystem handler you
want.  Can't do that under MS-DOS.  So you can use the CrossDOS filesystem
for your hard disk instead of FFS.  It won't be as fast, but you'll
probably be happy with it...

> Bela Lubkin    * *    //  filbo@gorn.santa-cruz.ca.us  CI$: 73047,1112 (slow)
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough