Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!h-sc1!breuel
From: breuel@h-sc1.UUCP (thomas breuel)
Newsgroups: net.micro.amiga
Subject: Re: AmigaDos...
Message-ID: <1084@h-sc1.UUCP>
Date: Wed, 30-Apr-86 13:07:58 EDT
Article-I.D.: h-sc1.1084
Posted: Wed Apr 30 13:07:58 1986
Date-Received: Sat, 3-May-86 04:46:14 EDT
References: <1076@h-sc1.UUCP> <615@jade.BERKELEY.EDU>
Distribution: net
Organization: Harvard Univ. Science Center
Lines: 90

||I can do an 'echo *' or 'ls' and don't have to wait for minutes.
|
|Minutes? How about a couple of seconds/file. That's closer to what I get.
|For ~20 files, AmigaDOS runs about half the speed of Unix. But Unix is
|running on an RA81 and AmigaDOS is running on a floppy.

It can take quite some time to list all the files in a directory,
into the 60 sec range for some of the disks I have.

||It appears that allocation blocks are not buffered, so that for
||each seek, Dos has to scan through the whole linked list on disk.
||Needless to say that this is dreadfully slow.
|
|Yeah - all two or three blocks. Some caching is done, though. At the end of
|this article, you'll find a program that times calls to Seek (the
|capitalization is correct - I used the AmigaDOS calls, not the stdio calls).
|The timings look flat, and suggest that the allocation blocks are cached, to
|some degree or another. The trackdisk buffer also shows up. It appears that
|doing a seek takes ~30 ticks, at least the second time you look in that area
|of the file (and I used a 700K+ file). But play with it yourself.  of
|course, seeks *DO* seem somewhat slow. Someone oughta play with it some more
|(but I'm not gonna).

Seeking through the two or three linearly linked allocation blocks
on disk can be excrutiatingly slow, however, if you have to do
it for every seek, and if they are scattered. This seems to be the
case for several of my disks. I can assure you that in several cases
I had a strong dependence of seek time on position in the file, i.e.
very fast seeks for the beginning, and long delays for seeks near the
end of the file.

Some arithmetic (correct me if I'm wrong): a file header block
or a file list block contains 72 block pointers, which represent
36k of data in a file. For a 720k file, the allocation table
can therefore grow to 20 blocks. For a search through a linear
chain of blocks, this is not insignificant anymore.

|The comment
|about doing globbing is true; I still can't figure out why they used
|globbing so heavily in the WorkBench.

It's because people like me forget their filenames so often :-).
A very large percentage of my CLI commands are dir's (on UN*X,
ls's). Likewise, most people probably prefer to be shown a dialog
box listing all available files, ready for click selection, to
a string dialog box.

|Sorry, but the AmigaDOS file system is probably less space effecient that
|Unix. You add one block for file header, then put the name and link
|information in each block in the file. The savings in the directory are
|neglible compared to this.

Well, the only savings are that a new, virgin directory costs nothing.
Nothing (other than speed on hashed directory searches) can really
be gained by moving the name from the directory into the inode, since
the amount of information about each file is still the same.

||Ultimately, I find that the current file system should be replaced
||with something more UN*X like (with name/inode pairs in directories,
||inodes, and links). I'm not saying this because I find the UN*X
||file system pleasing to the eye, but because it works, and because
|
|No, NO, NO! Going to an ilist with name/inode pairs DOUBLES the number of
|disk accesses to open a file by name! It also makes the file system less
|robust - a hit on the ilist is fatal to Unix, but the AmigaDOS file system
|can theoretically be recovered from any single-block hit. The AmigaDOS file
|system is theoretically faster than the Unix file system for most
|operations, the major exception being searching a directory. It trades space
|and links for robustness. On a home machine, this is a win - *IF* there's a
|tool for rebuilding broken disks. I understand that MetaComCo has one; why
|don't we have it?

I was not suggesting a file system *identical* to UN*X. But there are
other alternatives. Again, I personally favour the idea of tree-like
allocation tables (because it makes truely random accesses affordable).
Also, it can actually help save space greatly if it allows for small
'seedling' files (just one allocated block) like ProDos.

I believe that the loss of efficiency in 'open' by putting names back
into directories is tolerable. Furthermore, for large directories,
the name/inode-pair directory wins over the hash/bucket-list directory
again. If done carefully, the only thing that is lost in terms of
recoverability is that you may not be able to recover a file's name.
Otherwise, such a file system can be as robust as the current Amiga file
system.

Thanks for replying, and I hope people aren't bored by this
discussion.

						Thomas.