home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / wizards / 4548 < prev    next >
Encoding:
Internet Message Format  |  1992-11-06  |  1.5 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: SUN NFS sync
  5. Keywords: sync
  6. Message-ID: <15360@auspex-gw.auspex.com>
  7. Date: 5 Nov 92 23:28:06 GMT
  8. References: <1992Oct28.221355.9933@gupta.portal.com> <chris.720593732@suite.sw.oz.au>
  9. Sender: news@auspex-gw.auspex.com
  10. Organization: Auspex Systems, Santa Clara
  11. Lines: 25
  12. Nntp-Posting-Host: auspex.auspex.com
  13.  
  14. >It's unclear to me whether these
  15. >NFS implementations support the O_SYNC option or the fsync(2) system
  16. >call.
  17.  
  18. Some of them may not necessarily support *any* UNIX operations!  They
  19. aren't necessarily running UNIX....
  20.  
  21. I.e., the server can't support them as an NFS server, as there's no NFS
  22. request that corresponds to "fsync()", nor is there a flag on the NFS
  23. write operation that corresponds to O_SYNC.
  24.  
  25. O_SYNC, and "fsync()", are *client*-side functions - and, on many
  26. (probably most, if not all) UNIX implementations, they *are* necessary;
  27. the claim that
  28.  
  29. >The answer is: "You don't need to worry because the NFS protocol
  30. >specifies that all server writes are synchronous." This means that
  31. >your client file write system call won't return until the data is
  32. >actually on disk on the server. No sync is required.
  33.  
  34. isn't true.  The client file write system call can (as has been
  35. mentioned elsewhere in this thread) simply queue up the write to be done
  36. at some later time to the server.  The write in question will be
  37. synchronous on the server, but it's not necessarily going to be done as
  38. part of the client file write system call.
  39.