home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / clients / 270 < prev    next >
Encoding:
Text File  |  1993-01-12  |  2.8 KB  |  61 lines
  1. Nntp-Posting-Host: drott.ifi.uio.no
  2. Newsgroups: comp.client-server
  3. Path: sparky!uunet!mcsun!sunic!aun.uninett.no!nuug!ifi.uio.no!steinar
  4. From: steinar@ifi.uio.no (Steinar Kj{rnsr|d)
  5. Subject: Re: NFS slowness
  6. Message-ID: <1993Jan12.144759.2301@ifi.uio.no>
  7. Sender: steinar@ifi.uio.no (Steinar Kj{rnsr|d)
  8. Organization: Dept. of Informatics, University of Oslo, Norway
  9. References: <C0oB2y.AHE@news.iastate.edu> <1993Jan11.233316.989@newscan.canada.sun.com>
  10. Date: Tue, 12 Jan 1993 14:47:59 GMT
  11. Lines: 47
  12. Originator: steinar@drott.ifi.uio.no
  13.  
  14.  
  15. In article <1993Jan11.233316.989@newscan.canada.sun.com>, dennis@zonzorp.Canada.Sun.COM (Dennis Simpson Sun Canada) writes:
  16. > Maybe someone can save me digging up the answer.
  17. > When we are talking about "losing data" on the nfs server when using
  18. > the "evil asynch hack", are we talking about invisible loss? Or are we
  19. > talking about "fsck removed this corrupt file during reboot"?
  20. > 
  21. > I suspect the former (invisible), and if this is true, how can anyone
  22. > make the comment "we have had no problems using this hack"? Unless they
  23. > truly believe the gods are watching over them.
  24. > 
  25. > Just curious,
  26. > dennis
  27. > 
  28. > ---
  29. > /---------------------------------------------------------------------\
  30. > |  Dennis Simpson      dennis@canada.sun.com <at work>                |
  31. > |                      daddy!dennis@zonzorp.canada.sun.com <at home>  |
  32. > |  "I like the customer, in theory..."  - G. Rosser                   |
  33. > \---------------------------------------------------------------------/
  34. > 
  35.  
  36. I would like to think that the gods are watching me, but I don't think this
  37. is the reason we have encountered no problems so far.
  38.  
  39. I think you are running *about* the same risk as when you do normal buffered
  40. writes through the buffer-cache locally. Normally, the cache will be flushed
  41. automagically every nth second by the the update process (or any equivalent) 
  42. or by application generated sync() operations. 
  43.  
  44. If you for some reason experience a severe server crash between two flushes,
  45. you are a candidate for data loss. In a filesystem local to the server, fsck
  46. normally does a good job bringing the filesystem consistent again. So it does
  47. with any server-exported filesystem. However, the important difference now is what 
  48. happens on the remote client side before the remote application detects the
  49. server failure. I imagine there are worst-case situations where both remote
  50. pending unlink() and write() operations are involved, but I really don't know.
  51.  
  52. I would be happy to be corrected in the above assumptions by anyone more
  53. knowledgable than me in this case. The assumptions are based on a rough
  54. browsing through the source code for nfs_server.c on a SunOS 4.1.3 system.
  55.  
  56.  | Steinar Kjaernsroed    Dpt. of Informatics    email:steinar@ifi.uio.no
  57.  |            University of Oslo,               or
  58.  |                      NORWAY                        ..!mcsun!ifi!steinar
  59.  
  60.  
  61.