home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11927 < prev    next >
Encoding:
Text File  |  1992-12-24  |  2.3 KB  |  46 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!gatech!willis1.cis.uab.edu!hyatt
  3. From: hyatt@cis.uab.edu (Robert Hyatt)
  4. Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
  5. Message-ID: <1992Dec24.151500.11047@cis.uab.edu>
  6. Organization: University of Alabama at Birmingham
  7. References: <1992Dec21.194657.759@qb.rhein-main.de> <fW0DHHa@quack.sac.ca.us> <1992Dec24.112422.12434@titan.inmos.co.uk>
  8. Date: Thu, 24 Dec 1992 15:15:00 GMT
  9. Lines: 35
  10.  
  11. In article <1992Dec24.112422.12434@titan.inmos.co.uk> conor@lion.inmos.co.uk (Conor O'Neill) writes:
  12. >>
  13. >>That's an interesting point.  I am not an expert in Unix file access
  14. >>but I'd guess that Unix has standardized on both sequential
  15. >>and flat direct-access files, and that sequential access is just a
  16. >>special case of direct access: read so many bytes sequentially from
  17. >>a randomly-accessible point in a file.  Or, it has standardized on
  18. >>sequential file access, and that direct access is a special case, using
  19. >>the fseek() library call.
  20. >
  21. >But, given that 'fseek' is incredibly slow on most Unix systems,
  22. >one could almost assume that Unix doesn't support random-access files.
  23. >
  24.  
  25. If you look at how unix maintains a file's data blocks, you will see that
  26. it is based on random I/O.  There are direct pointers to the first ten
  27. blocks of a file, a pointer to a block of pointers for the next "n" blocks
  28. of the file (N depends on the blocksize/wordsize of the machine), a pointer
  29. to a block of pointers which points to blocks of pointers for the next
  30. n*n blocks of the file, etc.  In essence, everything is offset from the
  31. first byte of the file and there are no "links" or whatever within a
  32. block for sequential access.  To access a file sequentially, you simply
  33. increment through the pointers sequentially.
  34.  
  35. As to it being slow, I haven't noticed it being any slower than most any
  36. system call.... there IS a lot of work to cross the kernel boundary and
  37. then get back.  fseek() doens't do much work, just computes where the
  38. next block is.  If it is not pretty close to the last block (excepting
  39. the first 10 blocks of the file) it might have to do I/O to read in the
  40. "indirect" pointer blocks.  However, just like any system, random access
  41. has it's penalty.
  42.  
  43. -- 
  44. !Robert Hyatt                    Computer and Information Sciences   !
  45. !hyatt@cis.uab.edu               University of Alabama at Birmingham !
  46.