Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site x.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!mit-eddie!cybvax0!frog!x!john
From: john@x.UUCP (John Woods)
Newsgroups: net.unix-wizards
Subject: Re: Voodoo Practices
Message-ID: <510@x.UUCP>
Date: Tue, 21-May-85 12:38:04 EDT
Article-I.D.: x.510
Posted: Tue May 21 12:38:04 1985
Date-Received: Fri, 24-May-85 21:13:21 EDT
References: <867@sdcsvax.UUCP>
Organization: Charles River Data Systems, Framingham MA
Lines: 38

> <Huh?>
>     I have just begun to learn how to hack/program device drivers,
> and I seem to be seeing what might be called "voodoo" practices.
>     By "voodoo" I mean practices that are done ``Because they Work''.
>     3 syncs during a reboot.
This one is my favorite nervous habit.  I picked it up because I saw
someone else do it.  When I finally asked "Why more than one?" I got this
answer:  sync() does not wait until the last block leaves the write-behind
cache, it only schedules the blocks for flushing.  The second time you type
sync(), the shell requests /bin/sync to be brought in from disk again, and
this read request gets queued AFTER all those write requests.  Therefore,
when the second sync() executes, the first sync() is done (and the only
inconsistency is the date of sync(), which gets taken care of in a few
milliseconds).  "But why THREE?"  "Gee, I don't know......."

I offer the following solution to "But why THREE?".  I don't know if it has
any basis in historical fact, but it makes sense (and is therefore suspect).
If your disk is running with an elevator algorithm (requests are stuffed
inside the queue in track order, not merely appended to the end of the queue),
then the second sync might get picked up DURING the write-phase.  HOWEVER,
a third sync() will have to wait until the disk head changes direction AND
gets back to that point, by which time all of the write-behind should be gone.

As far as halt doing a sync, it may on the VAX, but the PDP-11 I use at MIT
doesn't have a halt() call (well, it may, but I've never used it...it is 2.9).
Ah, for the days when bootstraps were toggled in by hand!  (The MIT-CCC boot
is toggled in by hand, but consists only of stuffing a READ into the disk
register, and starting at 0:  the 45 and 70 both do DMA arbitration while the
processor is halted.  Thanks, DEC!)

[ The attitude implied here, ``If it don't fit in a 19" relay rack and doesn't
have switches, it isn't a *REAL* computer'', is not the opinion of my
employer, no matter *HOW* much I try to show them the light :-) ]
-- 
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA

"MU" said the Sacred Chao...