Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Directories
Message-ID: <13343@cbmvax.commodore.com>
Date: 20 Jul 90 21:36:50 GMT
References: <3541@monu1.cc.monash.oz> <13044@cbmvax.commodore.com> <8786@ubc-cs.UUCP>
Reply-To: jesup@cbmvax (Randell Jesup)
Distribution: na
Organization: Commodore, West Chester, PA
Lines: 22

In article <8786@ubc-cs.UUCP> panon@cheddar.ucs.ubc.ca (Paul-Andre Panon) writes:
>In article <13044@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes:
>>	This is one of the prime reasons we created ExAll.
>
>So, is there filesystem support for ExAll() such that the fs will "sort
>and read file headers in a sequential (i.e. only-increasing or only-
>decreasing block #'s) manner" when appropriate (ie. OFS or FFS)? This
>would have the nice bonus of speeding up directory listings, no?
>
>I guess what I meant was `is ExAll() atomic at the fs level, as well and
>do the OFS and FFS take advantage of that?'?

	In fact, we managed this for ExNext as well.  This is why it slows
down a lot if you UnLock() and re-Lock() on every ExNext (like the Manx
scdir and lattice dnext) - it has to rebuild the table, which may mean 
scanning until it finds the same entry again.  However, it's a BIG win under
normal operation.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"