home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / stratus / 93 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  1.7 KB
  1. Path: sparky!uunet!noc.near.net!transfer.stratus.com!sw.stratus.com!moser
  2. From: moser@sw.stratus.com (Tom Moser)
  3. Newsgroups: comp.sys.stratus
  4. Subject: Re: loss of end-of-file mark problem
  5. Date: 8 Jan 1993 17:00:10 GMT
  6. Organization: Stratus Computer, Inc.
  7. Lines: 27
  8. Distribution: world
  9. Message-ID: <1ikbuqINNrv9@transfer.stratus.com>
  10. References: <1993Jan7.131833.15374@porthos.cc.bellcore.com>
  11. NNTP-Posting-Host: iconoclast.sw.stratus.com
  12. Keywords: tps
  13.  
  14. In article <1993Jan7.131833.15374@porthos.cc.bellcore.com>, dante@decoy.uucp (25439-dante) writes:
  15. > In the event of a VOS crash, I have heard that it is possible that VOS
  16. > can lose a files's end of file mark, thereby corrupting the file and losing
  17. > access to the file on reboot.
  18.  
  19. This is not very likely if the file and directory data are already written to 
  20. disk at the time of the crash. File data and directory information which are
  21. updated in the file cache managers memory but not written to disk may be lost 
  22. in the event of a crash but the data can be flushed to disk using the s$control 
  23. system call with the runout_opcode.
  24.  
  25.  
  26. > The solution to the problem is to 
  27. > Transaction Protect(TP) the file. I was wondering if anyone has heard of
  28. > the problem and if so, then to discuss the problem and its possible 
  29. > solutions.
  30. > 
  31.  
  32. In general, transaction protection offers a much higher level of safety
  33. since it allows multiple file records to be updated atomically and thus 
  34. provides protection from interruptions which occur during a sequence of
  35. file writes which represent one transaction from the application. If the
  36. application can maintain integrety by simply insuring that sequential file
  37. writes are actually written to disk then the runout functionality can
  38. probably suffice.
  39.  
  40. -Tom
  41.