home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text0747.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  1.2 KB

  1. Received: (from srn@localhost) by flibble.cs.su.oz.au (8.6.9/8.6.9) id HAA26497; Tue, 2 May 1995 07:06:18 +1000
  2. From: Stephen Robert Norris <srn@flibble.cs.su.oz.au>
  3. Message-Id: <199505012106.HAA26497@flibble.cs.su.oz.au>
  4. Subject: Re: Possible way to improve Executor/Linux
  5. To: tjrc1@mole.bio.cam.ac.uk (Tim Cutts)
  6. Date: Tue, 2 May 1995 07:06:18 +1000 (EST)
  7. Cc: executor@nacm.com
  8. In-Reply-To: <9505010903.AA09434@mole.bio.cam.ac.uk> from "Tim Cutts" at May 1, 95 10:03:30 am
  9. X-Mailer: ELM [version 2.4 PL24]
  10. MIME-Version: 1.0
  11. Content-Type: text/plain; charset=US-ASCII
  12. Content-Transfer-Encoding: 7bit
  13. Content-Length: 558       
  14. Sender: owner-executor@nacm.com
  15. Precedence: bulk
  16.  
  17. > I have discovered that some filesystem problems with E/L 1.99k were
  18. > due to executor getting confused about the status of files, and that
  19. > this was particularly a problem with floppy access, and was solved by
  20. > manually sync'ing the filesystems in another window.  So, I figure
  21. > that perhaps executor ought to call sync(2) after every filesystem
  22. > write.  It would make it a bit slower, but might prevent a lot of
  23. > these problems.  Or has this been done with 1.99m?  (I haven't tried it
  24. > yet)
  25. > Tim.
  26.  
  27.     fsync(2) would be a better choice.
  28.  
  29.         Stephen
  30.  
  31.