🚀 go-pugleaf

[Mongo editing, please understand...]

In article <5565@pasteur.Berkeley.EDU> (David Ashley) writes:
> ... Amazing Computing,  ... it suggests a way
>of getting 18 percent more than the 880K on a normal 3.5 inch disk.

(different encoding maybe ?)

> It would mean storing data on the disk in a completely incompatable
> fashion.  The existing handlers for DFn: would have to somehow be
> replaced with new handlers, which would do their own disk read/writes
> rather than going through trackdisk.

In the 1.3 Mount command (coming soon to a store near you) there is an
option FileSystem=<handler> which lets you specify a handler when mounting
the device. You can also "unlink" a device from the device list so that
the system doesn't know about it. Thus you "unlink" DF1: and then Mount
it with a new handler. Voila, your running with the new handler.

> Maybe they can be turned off with an action_inhibit. Anyway, 18 percent
> is a worthy increase, and at the same time, improvements could be
> incorporated. I have seen IBM PC's, with their measly 8088, do very
> fast disk directories.  The directories must be stored in a fixed
> place, so that all the children can be accessed at once. The Amiga, on
> the other hand, stores file headers as linked lists so that to get a
> directory will require reads over the whole disk.

Dave, get a clue. Take that same "measly 8088" and start opening files
in a Hard disk directory with 200 - 300 files in it. Yes, the hashed
directory methods can be slower on wildcard searches, Yes they are almost
always faster on looking up a named file, Yes the layout of the disk
could be improved. It also allows for much larger disk sizes (I know
about the 52Meg limit in 1.2 but that was a bug and not a designed in 
limit). Caching the directory does the same thing for AmigaDOS as it does
for UNIX (ie makes it fast) then you get *both* fast directories and fast
lookups. Most of the floppy cache programs will let you do this easily 
(FACC being an excellent example here)

> Also better error checking could be used. The Amiga will throw away an
> entire track, 11 independent sectors, if any of the checksums in any of
> the sectors is bad. Don't let anyone fool you; this was a short-cut.
> The people that made the Amiga just didn't want to spend time trying to
> recover from disk errors, and they were in a hurry, so they ended up
> with a piece of shit method: too bad if you get an error.....

What are you talking about? A) Entire tracks are read which actually
increases performance if you really think about it, and B) What sort
of "recovery" is there from a screwed sector? Are you bitching about 
the disk corrupt requesters? There are ways to avoid those (like careful
use of disks) And many useful programs that help recover your data.

> What is FFS? Does it do this kind of thing? Store files in a different
> manner? Would it be profitable to work on this kind of project? Is 18
> percent increase in storage, faster directories, more reliable storage, and
> incompatability with the existing system worth enough?

FFS is a new handler that changes the way files are layed out on the disk
and to some extent the low level format of those files on the disk. It can
improve the disk speed by more intelligent use of the sectors. Writing
your own file system handler can be very instructive and if you want to 
learn about the tradeoffs made, by all means write one and try it out. Also
one has to realize the conditions under which the system software was 
written and is now being maintained (eg many ideas/projects not enough folks). 


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.