Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: DN10000 problems
Message-ID: <4e997ec6.1bc5b@pisa.ifs.umich.edu>
Date: 14 Dec 90 23:44:49 GMT
References: <677@tron.UUCP> <1990Dec14.192114.5310@alchemy.chem.utoronto.ca>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 25

In article <1990Dec14.192114.5310@alchemy.chem.utoronto.ca>, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes:

  To help with this problem, run 'update' from your /etc/rc file - Apollo
  will tell you it is not needed, but we have lost very few files in
  our many many crashes. Update does a 'sync' every 30 (?) seconds, not
  the many minutes that Domain/OS keeps disks up to date.

Actually, it's not so much that it's not needed as that it doesn't really do
what you think it does.  It doesn't write out everything as it would in,
say, Berkeley Unix.  All it does is force-write locked objects.  In the case
of remote objects that's good, since objects are always written out from
local memory when they're unlocked.  In the case of local objects, it's
possible to unlock a recently modified object, then call sync, and the
object won't get written to disk.

But it does help, even though it doesn't absolutely guarantee the integrity
of the disk.  Actually, bsd doesn't guarantee this either, since sync just
schedules writing, it doesn't really do it.  At least Domain/OS sync really
does the write.  To put it another way:  bsd sync is asynchronous; Domain/OS
sync is synchronous.

Domain/OS has a pair of processes, the purifiers (pids 3 & 4), that
progressively write dirty objects to disk.  I think they only write pages
from unlocked objects.  So the combination of the purifiers and sync should
be sufficient.