Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!hamilton
From: hamilton@uiucuxc.CSO.UIUC.EDU
Newsgroups: net.micro.amiga
Subject: Re: DOS filing system efficiency statis
Message-ID: <148600167@uiucuxc>
Date: Mon, 20-Oct-86 13:17:00 EDT
Article-I.D.: uiucuxc.148600167
Posted: Mon Oct 20 13:17:00 1986
Date-Received: Wed, 22-Oct-86 05:11:30 EDT
Lines: 37
Nf-ID: #R:<8610120648.AA24799@cory.Berkele:-38:uiucuxc:148600167:000:2052
Nf-From: uiucuxc.CSO.UIUC.EDU!hamilton    Oct 20 12:17:00 1986


>>> -I think it would be a good idea NOT to put the first data block on the same
>>> cylinder as the file entry.  You would then have double then number of 
>>> sectors on that cylinder to put file headers.
>>wayne hamilton:
>>    i think this was supposed to be a feature, so those small icon files
>>would cluster close to the directory and file headers.  hence the notable
>>speedup in icon plotting when Workbench drawers are opened.
>
>	You're correct.  However, you took my words out of context.  The idea
>is that if you have multiple track buffering, you still want to group the
>first data blocks together, just not put them on the same cylinder as the
>directory.  C-A's idea of putting the first data block on the directory
>track is a feature only if you do not have multiple track buffering, which
>we currently don't.
>
>	If you think about it, *everything* will go much faster with multiple
>track buffering and read-ahead.

    if you have multi-track buffering, _and_ your buffers are full of useful
data, you don't care if the file headers are segregated on cylinder A and
first blocks on cylinder B, or if they're mixed together across both A and B.
    but if you _don't_ have multi-track buffering, perhaps because you're a
consumer with a 256K machine, maybe you _will_ care.  and what about when
the intuition user inserts and opens a new disk?  the track buffers are
empty, but you want to get those icons on-screen as fast as possible.
    the file system _does_ need some tinkering.  but rather than trying to
devise some one-size-fits-all "ideal", i'd rather see something more adaptive.
there's still room for performance gains from minor changes, like following
those next-block pointers instead of reaching for the file header/list blocks.

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton%uiucuxc@a.cs.uiuc.edu	USMail:	Box 476, Urbana, IL 61801
CSNET:	hamilton%uiucuxc@uiuc.csnet	Phone:	(217)333-8703
CIS:    [73047,544]			PLink: w hamilton