Path: utzoo!utgpu!watmath!watdragon!rose!ccplumb
From: ccplumb@rose.waterloo.edu (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: A 1.4+ suggestion then...
Message-ID: <17355@watdragon.waterloo.edu>
Date: 18 Oct 89 21:01:32 GMT
References: <5599@ucdavis.ucdavis.edu> <8181@cbmvax.UUCP> <14003@grebyn.com>
Sender: daemon@watdragon.waterloo.edu
Reply-To: ccplumb@rose.waterloo.edu (Colin Plumb)
Organization: U. of Waterloo, Ontario
Lines: 24

In article <14003@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes:
>  May I then make a request for 1.5 (or 1.6 or whenever you decide to
> make incompatible changes to the filesystem): How about making
> the file index blocks in a tree? The first 72 pointers refer to data
> blocks, until there are more than 72. Then they point to the next
> level of index blocks, until there are more than 5184 (72 times 72).
> A linear search of the index blocks in a bad way to do things.
> Especially when on a hard disk with file sizes in the multi-megabytes.

First of all, they made incompatible changes to the filesystem in 1.3,
and everyone seems to be happy.  Hooray for modular software!  It's not
that big a deal to add another file system.

The other thing is, I'm sure the C-A crew are working on *much* more
interesting changes to the file system than just that.  One major
complaint is that the in-memory bitmap is pretty big (eats RAM) and
if it gets trashed by an errant program, it only gets detected later
when the system corrupts your disk.  Having the machine crash would
be preferable.  Making it a smaller target is another way.

Using less than 1 bit per disk block to manage a disk involves some
pretty major work.  There are lots of possibilities.
-- 
	-Colin