Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!h-sc1!breuel
From: breuel@h-sc1.UUCP (thomas breuel)
Newsgroups: net.micro.amiga,net.unix-wizards
Subject: Re: Speed of seeks
Message-ID: <1103@h-sc1.UUCP>
Date: Sat, 17-May-86 00:12:45 EDT
Article-I.D.: h-sc1.1103
Posted: Sat May 17 00:12:45 1986
Date-Received: Sun, 18-May-86 14:23:49 EDT
References: <12593@ucla-cs.ARPA> <645@baylor.UUCP>
Distribution: net
Organization: Harvard Univ. Science Center
Lines: 54
Xref: linus net.micro.amiga:6894 net.unix-wizards:15062

||Wait a sec... A Seek() call on the Amiga HAS to read every sector.
||
||Each sector on the amiga contains a (byte, word, long, whatever) indicating
||how much of the sector is used. So, if you want to read byte 600, you can't
||just go to the second record-- you have to go to the first, find out how
||much space it uses, go to the second, find out how much, etc.
|
|If this is the case, and if it is also the case that the Amiga directories
|don't contain the file names (what do they contain? a hash table?), then C=
|Amiga has some serious redesigning to do before I or anybody I know actually
|go out and buy this thing.

No, this is not true. A Seek() call has to read the block allocation
list, a linked list of pointers to blocks allocated to a file.
Each block, except for the last one, is filled (or at least considered
to be filled for the purpose of Seek's). This means that for every 72
blocks in the file (36k) there is another block in the block allocation
list. Therefore, for large files (720k), a seek may have to go
through as many as 20 blocks in the block allocation list, which
can be quite slow. This was the point of my original complaint.
Supposedly, something is being done about this in 1.2, although
nobody from C/A has said anything specific as to *what* is being
done. My proposals are: (1) change the file system to use allocation
trees (2) buffer all allocation pointers for a file in memory (as
a backwards compatible fix; on a two drive system, this can mean
at most 20k of memory and gives the fastest seeks possible).

|Incidentally, despite the poor design of the files a seek() does not have to
|read every sector... a mistake often made by library writers is to try to
|make seek offsets simple integers. According to the library, the argument
|to an absolute seek() (lseek(fd, off, 0) or lseek(fd, off, 2)) only needs
|to be the returned value from a tell() call: it may indeed be a magic cookie
|like a sector/offset pair (and in fact "magic cookie" is the way it's described
|in the manual). It is under RSX/11M and on the ATARI 800.

Both lseek and fseek are guaranteed to seek to byte offsets under
UN*X (2.9). There may be systems with other behaviours, but I would
not want to be forced to use such a disaster...

|It's not
|meaningful to seek to an unknown depth in a text file or other weird file
|anyway.

Sure it is. You can do a binary search (and gain by doing it) even if
you don't have a fixed record length.

|The Lattice 'C' runtime library on the IBM-PC has an obscure bug related to
|this, by the way, so I'm not surprised they screwed up their Amiga library
|too...

I'm not sure what you mean by this. The Lattice runtime library
has (fortunately) nothing to do with the Amiga file system.

						Thomas.