home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / aix / 13216 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  1.8 KB
  1. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!spool.mu.edu!uwm.edu!ogicse!das-news.harvard.edu!endor!adam
  2. From: adam@endor.uucp (Adam Shostack)
  3. Newsgroups: comp.unix.aix
  4. Subject: Re: Prestoserve
  5. Keywords: I/O, disk
  6. Message-ID: <1993Jan12.150405.26425@das.harvard.edu>
  7. Date: 12 Jan 93 15:04:05 GMT
  8. Article-I.D.: das.1993Jan12.150405.26425
  9. References: <1irvnlINNhlk@corax.udac.uu.se>
  10. Sender: usenet@das.harvard.edu (Network News)
  11. Organization: Aiken Computation Lab, Harvard University
  12. Lines: 30
  13.  
  14. In article <1irvnlINNhlk@corax.udac.uu.se> larsowe@csd.uu.se (Lars-Owe Ivarsson) writes:
  15.  
  16. >      Rumor has it that Legato is working on a Prestoserver for the RS/6000.
  17. >I thougt a Prestoserver, as used by Sun and Dec, was a kind of disk-cache.  
  18. >As many operating systems--e.g. AIX and IRIX, unlike SunOS and
  19. >Ultrix--use memory-mapped files, I assumed that the operating system
  20. >would take care of that (given enough memory at least), making a
  21. >prestoserver unnecessary on IBM and SGI systems, or at least not cost
  22. >justified.  Obviously I was wrong on that, so if anybody would please
  23. >explain the Prestoserve concept for me, especially in combination with
  24. >the RS/6000, I would be very grateful.
  25.  
  26. An NFS client waits for a response from the server saying "ok, I wrote that
  27. packet to disk."  Since disk is slow, and can be heavily loaded down,
  28. the prestoserve has (battery backed up?) ram, and sends the ACK as
  29. soon as it recieves the packet.  
  30.  
  31. That way, NFS writes are not slowed down by a heavily loaded server,
  32. waiting to write the packet.
  33.  
  34. Does aix map a file into ram and then not guarantee it is written to
  35. disk until it is close()ed?!?
  36.  
  37. Adam
  38.  
  39.  
  40. Adam Shostack                     adam@das.harvard.edu
  41.  
  42. What a terrible thing to have lost one's .sig.  Or not to have a .sig
  43. at all.  How true that is.
  44.