Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!oliveb!amiga!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga.tech Subject: Re: AmigaDos directory knowledge Message-ID: <8742@cbmvax.UUCP> Date: 28 Nov 89 20:57:35 GMT References: <88.filbo@gorn.santa-cruz.ca.us> Organization: Commodore Technology, West Chester, PA Lines: 112 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