Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!sun!swap!page
From: page%swap@Sun.COM (Bob Page)
Newsgroups: comp.sys.amiga.tech
Subject: Re: fib_DiskKey semantics
Message-ID: <104761@sun.Eng.Sun.COM>
Date: 15 May 89 05:53:33 GMT
References: <1989May12.183725.25380@ziebmef.uucp>
Sender: news@sun.Eng.Sun.COM
Reply-To: page@sun.UUCP (Bob Page)
Organization: Sun Microsystems, Mountain View
Lines: 46

You walk on rice paper, grasshopper.

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 just did some
testing with the "pickpacket" program and everything looked OK on OFS;
I didn't get too far into testing FFS when I sent a bad packet and
hung the task (in fact I have a requester telling me to finish up all
disk activity and reboot right now)).  If you want to know about all
the other handlers, you'd going to have to ask them.

At one session during the last Amiga Developer's Conference (May '88)
Steve Beats (Commodore's Mr.Filesystem) asked how many people were
writing their own file system.  Over two dozen people raised their
hands.  Steve (after his shock) said he'd put together a document to
help those folks out, including all the stress points you have to pass
with Workbench, which is very file-system nasty.  I never saw the
document, maybe others did, or maybe he's finishing it up for the
DevCon next month. ;-)

On directory formats, I'd go for fast directory scans at the expense
of file open speed.  The difference won't be noticable at the open()
call, but will be at the scan, since any increase in scan time is
cumulative for each file.

I happen to *like* the FFS directory format, except I'd like to have
the file names in the directory header, which would make scans much
faster if you didn't need the fib.  Since it's relatively atomic
(you'll have to read several disk blocks for a large directory) you
lose all the funky race conditions that ExNext has.  For applications
like file requesters, or pattern matches, or shell file-name
completion, you win big time.  It means directories take up more
space, but I think it's worth it, and would give the Amiga a
radically different feel.

For compatibilty, you can instruct programmers to add some magic
cookies in Arg3/Arg4 (like arg3: 0xf0f0a5a5, arg4: *char buffer)
before they call ExNext, that tell ExNext implementations "in the
know" they're only interested in a bulk file name dump, not individual
fibs. The return code would tell the program whether it got a "new"
ExNext or an old one.

[Gotta reboot my machine.  How come layers are so slow when a
requester is up?  Somebody do a Forbid()?  Is this needed?  The
de-dicer is so slow I feel like I'm working on a Sun. :-) ]

..bob