Path: utzoo!attcan!telly!ziebmef!mcp
From: mcp@ziebmef.uucp (Marc Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: fib_DiskKey semantics
Message-ID: <1989May22.162035.19970@ziebmef.uucp>
Date: 22 May 89 20:20:33 GMT
References: <1989May12.183725.25380@ziebmef.uucp> <104761@sun.Eng.Sun.COM>
Reply-To: mcp@ziebmef.UUCP (Marc Plumb)
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 62

Bob Page wrote:
> You walk on rice paper, grasshopper.

It's trickier than I thought at first.

> Since a disk key in a Lock is a physical block number, it should be
> easy to see if the fib_DiskKey corresponds to it.

I know this is how the old file system does it, but I'm *writing*
a new handler, not using an existing one, so I want to know what
undocumented or obscure features of the old ones people use so
I can try to give the sinners time to repent.  My file system is *very*
different from the current ones and there is no obvious analogue.

Steve Beats' document sounds very interesting, if only I could get my
hands on it.  In the interim, the series in the Amiga Transactor seems
to be the best thing going.

I think the FFS directory format is incredibly wasteful.  In my system,
a small (up to a few K) file "foo" has about 30 bytes of overhead
(including entry in parent directory), so a 1-byte file takes 31 bytes
of disk space.  FFS uses 1K.  Half a K for an empty file?  I need about
23 bytes.  While I do use the pointers-to-file-headers scheme, the
headers' small size lets me keep lots on one track and I use clustering
heuristics.  The hashing is a neat idea - I use a 256-way hash myself.
This produces fast failed opens, which is needed for path searching.

Your idea of providing a different way to get a directory listing is
nice, although I don't understand the suggested implementation.  One
way is just to use open/close/read/write and return a data stream in
a standard format.  This conflicts with the PATH: device, but I think
Rico will survive.  Or why not just create a new call that uses locks
instead of FIBs and also returns the file's name (and maybe a file/dir
bit).  You could Examine() the lock if you need more info, Open() it
if you want the file (no race condition), or pass it back to the call
(null lock passed starts a directory scan, null lock returned indicates end)
to get the next one.  Or DupLock() the lock if you're globbing to a list
of files and want to build it up, or just drop the lock and end the
scan.  A handler that didn't understand this would return a packet not
understood error and you could fall back to ExNext.

Anyway, thanks for the vote for scans over opens.  While I've already
decided most things, I was considering a hack for .info files that would
keep small files with their headers, reducing the number of headers that
would fit on a track.  I think I'll punt on that, unless I want to
let the file system know that files with names ending in ".info" should
be optimised this way.  It's a premature optimisation, anyway.

(I've just gone and talked to a few people who actually *use* WorkBench,
and they've convinced me to at least look at the problem.  I've got
a fair bit to do before then, though.)

I'm trying really hard for killer directory speeds.  We'll see...

I've rambled a bit.  Oh, well.  I just worked out a scheme that would
let me return DiskKeys in permanent one-to-one correspondence with
files and use only them to keep track of my position in a directory
listing, but it requires keeping 6 bytes per entry in the directory
being scanned for the duration of the lock being ExNext()ed along.
Does that seem reasonable?
--
	-Colin Plumb