Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!ctnews!pyramid!batcomputer!itsgw!csmbox!rpics!guilford
From: guilford@rpics.RPI.EDU (Jim Guilford)
Newsgroups: comp.sys.amiga
Subject: Re: Workbench improvements
Message-ID: <1129@rpics.RPI.EDU>
Date: Sat, 25-Apr-87 21:21:21 EDT
Article-I.D.: rpics.1129
Posted: Sat Apr 25 21:21:21 1987
Date-Received: Sun, 26-Apr-87 23:24:21 EDT
References: <3291@jade.BERKELEY.EDU>
Distribution: na
Lines: 22
Summary: Possible improvement?



As long as we are talking about workbench improvements, I'll throw in my two
cents (I hope I am not out in left field :-)

I've noticed that it takes a lot longer to write a file than to read it. I
would assume that this happens because of the following.
It seems to me that when one is extending a file that they system must
allocate a new disk block, update the record of what blocks are in use, and
then write the actual data block. Since these are probably widely separated
on the disk, a lot of head seeking needs to be done. Might it not be more
efficient that when one needs a new block for a file, to grab multiple
blocks (if they are available), and then when the file is closed, return any
unused blocks. This would reduce the number of times that the disk
allocation area has to be updated and hence speeds the file expansion.

I haven't actually studied the disk format, so I may be far off. But if my
assumptions are accurate, I think that this would be a relatively painless
way to improve disk speed on file extension.

--Jim Guilford
(guilford@csv.rpi.edu)