🚀 go-pugleaf

In article <1992Dec24.112422.12434@titan.inmos.co.uk> conor@lion.inmos.co.uk (Conor O'Neill) writes:
>>
>>That's an interesting point.  I am not an expert in Unix file access
>>but I'd guess that Unix has standardized on both sequential
>>and flat direct-access files, and that sequential access is just a
>>special case of direct access: read so many bytes sequentially from
>>a randomly-accessible point in a file.  Or, it has standardized on
>>sequential file access, and that direct access is a special case, using
>>the fseek() library call.
>
>But, given that 'fseek' is incredibly slow on most Unix systems,
>one could almost assume that Unix doesn't support random-access files.
>

If you look at how unix maintains a file's data blocks, you will see that
it is based on random I/O.  There are direct pointers to the first ten
blocks of a file, a pointer to a block of pointers for the next "n" blocks
of the file (N depends on the blocksize/wordsize of the machine), a pointer
to a block of pointers which points to blocks of pointers for the next
n*n blocks of the file, etc.  In essence, everything is offset from the
first byte of the file and there are no "links" or whatever within a
block for sequential access.  To access a file sequentially, you simply
increment through the pointers sequentially.

As to it being slow, I haven't noticed it being any slower than most any
system call.... there IS a lot of work to cross the kernel boundary and
then get back.  fseek() doens't do much work, just computes where the
next block is.  If it is not pretty close to the last block (excepting
the first 10 blocks of the file) it might have to do I/O to read in the
"indirect" pointer blocks.  However, just like any system, random access
has it's penalty.

-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !