Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site h-sc1.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!h-sc1!breuel
From: breuel@h-sc1.UUCP (thomas breuel)
Newsgroups: net.micro.amiga
Subject: AmigaDos...
Message-ID: <1076@h-sc1.UUCP>
Date: Wed, 23-Apr-86 21:41:43 EST
Article-I.D.: h-sc1.1076
Posted: Wed Apr 23 21:41:43 1986
Date-Received: Sat, 26-Apr-86 03:48:44 EST
Distribution: net
Organization: Harvard Univ. Science Center
Lines: 52

A complaint, and two questions:

I have philosophical problems with the AmigaDos file system.
The file system appears to be optimised for finding a named entry
quickly and for making directories small and cheap: the directories
are hashed and do not contain the filenames. This means that for
wildcard expansion and select-file-dialog-box'es, one block has
to be read for each entry in a directory.

An unrelated, but (philosophically) similar problem is the use
of linear, linked blocks for file allocation tables.
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.

The above two problems are compounded by the apparent lack of any
attempts to allocate, say, all allocation blocks on the same track
so that scanning through the allocation list may require many seeks.

Now, even if the above statements are not entirely accurate, the fact
remains that the AmigaDos file structure is, for practical purposes,
too inefficient. It discourages seeks and discourages directory scans.
Instead it gives some (doubtful) savings due to small directory sizes
and simplicity of algorithms for seeks (read lazy programmers ?!).

I'm not writing this purely because I disagree with the file system
structure in some abstract manner, but because for several applications,
this file system is almost unusable (e.g. picking characters out of
a 700k Kanji font file).

It should also be noted that a simple disk cache at the disk driver
level is not necessarily going to improve matters. What is really needed
is a way to instruct Dos to keep the allocation tables for a specific
file in memory.

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
I can do an 'echo *' or 'ls' and don't have to wait for minutes.

So, one question, you have seen already: I need a workaround to access
random parts of a large file quickly. I would greatly prefer not to split
the file up... (and that wouldn't necessarily help anyhow).

The other question is: how are the ROM Kernel and AmigaDos actually
glued together? Where and when is each part of the OS loaded? 
Are there hooks for user file system code (e.g. to implement a remote
file system)? Pointers to the documentation or straight answers
would be appreciated.

						Thomas.