Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!cornell!uw-beaver!microsoft!w-colinp
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Faster File Systems
Summary: Comments!
Keywords: BOOH
Message-ID: <85@microsoft.UUCP>
Date: 16 Dec 88 02:21:12 GMT
References: <65@microsoft.UUCP> <23498@sgi.SGI.COM>
Reply-To: w-colinp@microsoft.UUCP (Colin Plumb)
Organization: Microsoft Corp., Redmond WA
Lines: 55
Confusion: Microsoft Corp., Redmond WA

< 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.

In article <23498@sgi.SGI.COM> scotth@harlie.SGI.COM (Scott Henry) writes:
>The biggest problem that I see with your scheme is that it will only work
>with floppy disks (hard disks need not apply). The hard disks that I am aware
>of know about sectors (frequently, in the case of SCSI, in the drive itself).
>OFS works fine on HD's, but your scheme would need a separate file system
>for HD's. I know of (at least) one extent-based HD file system (Silicon
>Graphics uses one), but it uses sectors as the level of granularity (this
>is all I know about it!, except that it is very fast).

True, I was being pretty silly; the rest of the world uses sectors, so
dropping them can cause problems.  Still, it's an idea to play with.  As
far as my filesystem design is concerned, I explicitly said it's only for
floppies.

I have been involved in writing an extent-based file system (yes, we
(old we, not Microsoft) also use sector granularity), and it does go
plenty fast.  I was planning on reimplementing it for the Amiga, but
as long as I only have floppy drives to play with, I decided to optimise
the hell out of that particular piece of hardware.

Now, come on, people... I'm not entirely ignorant, but my Amiga-specific
abilities are pretty low.  Aren't there any horrible, insuperable problems
with taking the drive away from DOS, or automatically recognising the
format of floppies inserted, or handling disk changes, or making WB
recognise the disk, or something?  And I said nothing about directory
structure... my current idea is simply to let the directory inode contain a
variable-sized (up to 1 track) array of struct {short inode; short hashval} 
putting a limit of about 2500 files in a directory.  The longer hash value
should essentially eliminate collisions, and the fact that all inodes are
known should speed up directory searching.  Is this fair, or should I do
something else?  If I allow inodes to migrate across tracks, what does
this mean for ExNext() if I want it to proceed in track order?

Also, should it be case-sensitive or not?  (I'll at least throw in a
compile-time switch.)  Should I take the filename out of the inode and
allow hard links?  Should it have Unix-like open-file-deletion semantics?
Should I add something (another datestamp?) to inodes?  Should it allow
sparse files?  Will FCFS access be good enough, or should I try and
optimise accesses in the queue?  Any special packets I should implement?

Isn't *anyone* going to flame me for not building in some super-nifty
virus-checking algorithm or something? :-) :-) :-) :-)

Finally, question for C-A: will WB 1.4 support variable-sized lock structs?
If so, I might find it easier to use them now, not work with this WB, and
just wait for 1.4.  It's unlikely to get out of the CLI-bigot community
before then, anyway.

BYW, thanks for the RDF: device; it's a pointer in the right direction.
-- 
	-Colin (uunet!microsof!w-colinp)