dillon@cory (04/27/86)
As Thomas mentioned earlier, the AmigaDos filesystem does seem to have some problems. Yup... It very definately is 'optimized' for finding a single file fast. However, it has backfired miserably for two reasons: (1) The disk is not cached (that pitiful track-buffering is NOT a cache) (2) It may find files fast, but you cannot get directories, or any other type of multiple file expansion without putting the stepper motor through pure hell. Assuming you don't have so many files as to cause multiple links from the hash, the one major failing of AmigaDOS is that the only way to figure out the name of a file is go to that file's header block. Nothing about the file is stored in the 'directory'. The track caching is a big loose. It only works when you are reading or writing one file at a time, and even then it doesn't work all that hot since the system allocates blocks in a half-hazard manner anyway. EXAMPLE: If you create 10 sub directories BEFORE you begin sticking stuff into them, getting a directory of the root is quick because all the sub-directory's nodes are near the root node. HOWEVER, if you create the 10 sub directories one at a time, sticking files in them as you go along, getting a directory of the root becomes an order of magnitude slower because the sub directory's nodes are nowhere near the root's node or each other. SOLUTION: (1) Scrap your 'hash' table and go with a 'the directory is a file to' way of looking at things.. e.g., a linear list with the file names (at the very least) accesable without going to the inode. Doing things this way (coupled with REAL caching) gives you extremely fast access. (2) Put in some REAL caching. That means save accessed blocks and include access frequency information (thus one-time-reads have little effect, and multiple-use of file/dir nodes stay in)... most of your linear file searches will then be memory searches rather than seek searches. Since your disk driver can only read in a track at a time, I suggest you keep the track buffering.. for only a single track, but abstract it from the cache since future disk's will probably use REAL controllers. This will solve (for the mose part) the following problems as well: * Keeping the root block in memory * Keeping file allocation tables in memory. (3) Linked list sector's went out a decade ago. Only commodore was stupid enough to use linked list sector's in their disk format. Get rid of your 'linked list' disk format and put some REAL side sectors in... I'm talking about log-type expanding side sectors (ROOT sector table has say, 64 entries to sectors, 32 entries to sector-tables, 16 entries to sector-tables to sector-tables... etc...) This gives the following: * You can seek anywhere quickly * You can perform intelligent sector lookahead operations Thomas writes: >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. Well I'm saying it.... the 4.2 BSD filesystem is fast, efficient, and one of my favorites. You could fit most of its concepts in a file-system fit for the Amiga. -Matt
sgt@alice.UucP (Steve Tell) (05/14/86)
Since device drivers (including the filesystem) on the amiga are tasks, shouldn't it be possible to write such a task that used the trackdisk device and implemented some other kind of file system on a raw disk? Then everyone who wants to try out another kind of filesystem can do it, and provide us with some real information on what's better. It would also open the door for remote file systems, etc. I suppose you might have a bit of trouble keeping the existing filesystem task out of your way. Anyone who knows more about this care to comment, and say if this is easy, hard, or insane?