home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11860 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.0 KB

  1. Xref: sparky comp.arch:11860 comp.sys.dec:6593 comp.sys.sgi:18269 comp.sys.hp:14311
  2. Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
  3. Path: sparky!uunet!usc!sol.ctr.columbia.edu!usenet.ucs.indiana.edu!fractal!mdchaney
  4. From: mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney)
  5. Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
  6. Message-ID: <Bzo3tJ.KGo@usenet.ucs.indiana.edu>
  7. Sender: news@usenet.ucs.indiana.edu (USENET News System)
  8. Nntp-Posting-Host: fractal.ucs.indiana.edu
  9. Organization: Indiana University, Bloomington
  10. References: <BzIxqo.C90@dscomsa.desy.de> <BzKGKB.2Bp@pix.com> <1992Dec21.103432.294@rlgsc.com>
  11. Date: Tue, 22 Dec 1992 15:46:31 GMT
  12. Lines: 52
  13.  
  14. In article <1992Dec21.103432.294@rlgsc.com> gezelter@rlgsc.com writes:
  15. >In article <BzKGKB.2Bp@pix.com>, stripes@pix.com (Josh Osborne) writes:
  16. >> The we need a way for user level code to tell the OS what file info is
  17. >> important to cache, and what isn't.  Then you can be almost as efficent
  18. >> as VMS/RMS (you will have extra context switch overhead for the extra
  19. >> syscalls), but you will still be able to allow any user to create new
  20. >> filetypes.
  21. >-- 
  22. >Josh,
  23. >Important point that you bring up tangentially in your post. 
  24. >While VMS does provide RMS as an operating system service, there 
  25. >is nothing which prevents you from "folling your own" type of 
  26. >file structure. However, every program which wants to read from 
  27. >your special file structure will have to be intimately familiar 
  28. >with it. Programs which use RMS can process files which were 
  29. >created using RMS with no problems.
  30. >A misnote about the HSC which appeared in this thread. The HSC 
  31. >does not really know anything about the content of the disk 
  32. >files. However, RMS will do things inside of the CPU, such as 
  33. >maintain index caches on a system wide basis, which are a 
  34. >signifigant performance improvement. One problem with rolling 
  35. >yourself is that, invariably, the management and monitoring tools 
  36. >and utilities are bare-bones.
  37. >- Bob
  38.  
  39. Actually, I've seen alot of people here call RMS "the file system."  For those
  40. of you who still think that RMS is the file system, I'll clue you in: RMS
  41. is not the file system.
  42.  
  43. Let's think of what RMS stands for: "Record Management Services."  Hmm, sounds
  44. more like a record manager than a file system, doesn't it though.
  45.  
  46. The file system is accessed via QIO calls, and knows nothing about file
  47. formats.  All it knows about is disks and files, files via file ids.  It is
  48. actually easy to open a file by id and read virtual blocks from it.  If you
  49. want to roll your own Unix functions (fread and fwrite), this is the way
  50. to do it.  It might be a little faster, and you needn't worry about RMS.
  51.  
  52. For stream-lf files, just buffer those blocks, and keep track of where the
  53. lf is.  It's not difficult, and you can easily get around the 65534 limit
  54. that RMS places on files.  Have fun...
  55.  
  56.     Darrin
  57.  
  58. -- 
  59.  
  60. mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu
  61.  
  62. "I want- I need- to live, to see it all..."
  63.