Path: utzoo!attcan!uunet!cbmvax!steveb
From: steveb@cbmvax.UUCP (Steve Beats)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Faster File Systems
Keywords: BOOH
Message-ID: <5512@cbmvax.UUCP>
Date: 15 Dec 88 17:21:15 GMT
References: <55@microsoft.UUCP> <65@microsoft.UUCP>
Reply-To: steveb@cbmvax.UUCP (Steve Beats)
Organization: Commodore Technology, West Chester, PA
Lines: 43

In article <65@microsoft.UUCP> w-colinp@microsoft.UUCP (Colin Plumb) writes:
>
>P.S. I've received a few replies, but so far it seems as if I'm the best FS
>designer in this newsgroup.  Isn't anyone going to prove I'm not? :-)
>Really, there must be *something* wrong, or the Amiga wouldn't have been
>designed with sectors in the first place.
>-- 
>	-Colin (uunet!microsof!w-colinp)

I did take a brief scan over your original posting and will grant that it
has a few nice features *FOR FLOPPIES*.  The point is that the filing
system really makes minimal use of the tracks/sectors/heads information.
The only thing affected by this is the placement of file headers with 
respect to the data blocks.  If I were to take your filing system and
try to hook it up to some remote device driver (one that gets its data
across a network for instance) all of the optimisations you mentioned
would do nothing but waste time!  Even ramdrive.device (although it does
present itself as a disk) would not benefit from this scheme.  The beauty
of the filing system as it stands now, is that it can interface to just
about any device that takes a logical offset for read and write commands.

This is similar to a recent thread we had about bad block mapping in the
file system.  I don't think it's appropriate for the filing system to
become too rigidly attached to the geometry of the media it's accessing.
While local optimisations are important, you have to be really carefule
about things that change from one drive type to another.

I still maintian that the driver (which *HAS* to know about the media it
is accessing) should be responsible for bad block mapping.  In the same
vein, the driver should be responsible for local speed optimisations
based on the hardware it is controlling.

(I've actually been forced to practice what I preach since I'm just
finishing up a new device driver for a new hard disk controller).  It's
interesting to note that this viewpoint can also be applied to lower
level system software too.  For instance, many hard disk drivers provide
some speedups by cacheing tracks in an LRU manner.  While this does speed
up the majority of slow devices, it ends up wasting CPU time and memory
when I higher dollar SCSI drive is used.  A case in point is the Quantum
40S and 80S drives that have a 64K read ahead cache built in.  All these
drivers end up doing is cacheing the cache; a somewhat pointless excersise.

	Steve