home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / software / 2919 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.6 KB
  1. Xref: sparky comp.software-eng:2919 comp.arch.storage:527 comp.unix.internals:1583
  2. Path: sparky!uunet!auspex-gw!guy
  3. From: guy@Auspex.COM (Guy Harris)
  4. Newsgroups: comp.software-eng,comp.arch.storage,comp.unix.internals
  5. Subject: Re: Extent-based Filesystems (was: Large Application data sets )
  6. Message-ID: <13673@auspex-gw.auspex.com>
  7. Date: 22 Jul 92 21:35:52 GMT
  8. References: <33120@cbmvax.commodore.com> <1992Jul21.113652.4898@metapro.DIALix.oz.au> <1992Jul22.194214.20451@sequent.com>
  9. Sender: news@auspex-gw.auspex.com
  10. Followup-To: comp.software-eng
  11. Organization: Auspex Systems, Santa Clara
  12. Lines: 39
  13. Nntp-Posting-Host: auspex.auspex.com
  14.  
  15. >Every proprietary OS I can think of has strongly typed files and that 
  16. >means extenting.
  17.  
  18. Err, could you please explain how "strongly typed files" "means
  19. extenting", by which I assume you mean that any OS with "strongly typed
  20. files" is therefore required to have an "extent-based file system"?
  21.  
  22. I don't see how having "strongly typed files" - by which I assume you
  23. mean files where the standard "access method"s provide more than just
  24. access to a random-access stream of bytes (or words, or whatever), and
  25. where one of the attributes stored with the file is, in effect, the
  26. access method to be used when accessing the file - requires an
  27. extent-based file system.
  28.  
  29. In fact, I seem to remember reading, a long time ago, something from
  30. Apollo indicating that the underlying bucket-o-bytes in the file system
  31. was implemented in a fashion somewhat similar to the fashion in which
  32. the UNIX V7 file system implements its bucket-o-bytes, i.e. some number
  33. of direct block pointers pointing to the first few fixed-size blocks in
  34. the file, some number of indirect block pointers pointing to fixed-size
  35. blocks containing pointers to the next N fixed-size blocks in the file,
  36. etc..
  37.  
  38. I.e., they didn't have an "extent-based file system", by which I assume
  39. you mean a file system wherein the file map is a set of "extents", each
  40. extent saying "the next N blocks of the file are the N blocks of the
  41. disk or partition starting at block X".
  42.  
  43. I also think that, at the time, they had strongly-typed files in the
  44. above sense, although I don't think they'd yet implemented the scheme
  45. that lets *new* types be added - it just had a fixed set of access
  46. methods.
  47.  
  48. Now, given that the *underlying* file system mechanisms *did* provide, I
  49. think, a bucket-o-bytes, which got mapped into the process's address
  50. space, either by the application itself or by the "access method" code,
  51. maybe that doesn't count as an OS with "strongly typed files" (in which
  52. case there now is a proprietary OS you can think of that doesn't have
  53. strongly-typed files, namely Aegis).
  54.