home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 188 / text0000.txt < prev   
Encoding:
Text File  |  1990-12-05  |  1.2 KB  |  33 lines
  1. Submitted-by: nick@bischeops.uucp (Nick Bender)
  2.  
  3. In article <13218@cs.utexas.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  4. = Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  5. = 
  6. = In article <551@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  7. = > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  8. = > >NFS (as it is currently implemented) shows what goes wrong when
  9. = > >reliability disappears.
  10. = > In a discussion of filesystem semantics, NFS is a straw man.  Everyone
  11. = > knows it's a botch.
  12. = > If AFS and RFS don't convince one that a networked filesystem
  13. = > namespace can work well, then nothing will.
  14. = 
  15. = Exactly! This example proves my point. What's so bad about NFS---why it
  16. = doesn't fit well into the filesystem---is that it doesn't make the
  17. = remote filesystem reliable and local. If you show me Joe Shmoe's RFS
  18. = with reliable, local, static I/O objects, I'll gladly include it in the
  19. = filesystem.
  20. = 
  21. = ---Dan
  22.  
  23. Any program which assumes that write(2) always works is broken. Period.
  24. That's why you sometimes get long streams of "filesystem full" on your
  25. console when some brain-damaged utility doesn't check a return value.
  26. In my view this is not a reason to call NFS a botch.
  27.  
  28. nick@bis.com
  29.  
  30.  
  31. Volume-Number: Volume 21, Number 188
  32.  
  33.