hutch@sdcsvax.UUCP (Jim Hutchison) (05/16/85)
<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. One is supposed to do it, yes?no? !?!
Sync before a halting? Halt syncs! There are several more no doubt.
Will someone kindly elucidate, please? If no elucidation is possible,
does anyone have a *list*, mental or otherwise, that they can post?
--
/*
"When you are dying, a wombat is better than no company at all."
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: hutch@sdcsvax
< Ofcourse these statements are only mine, not my employers. >
*/john@x.UUCP (John Woods) (05/21/85)
> <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...
mrl@drutx.UUCP (LongoMR) (05/22/85)
>> 3 syncs during a reboot. One is supposed to do it, yes?no? !?!
It is my understanding that this is a carry over from the OLD
days of UNIX (Pre 2.0) when one sync command or system call would
either (a) return before the update to disk was complete or (b) not
do a complete update (I am not sure which one, I have heard both).
In either case it is not necessary any more, but I do it anyway.
The additional calls don't hurt anything, and additional time is minimal since
there is nothing queued to be written after the first sync completes.
Mark Longo AT&T ISL Denver
Here's my clever saying...
`don't worry whether I'm right or wrong.. someone will correct me
either way!'dan@rna.UUCP (Dan Ts'o) (05/23/85)
In article <> john@x.UUCP (John Woods) writes: >> <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 Well on the UNIXs I know about this explanation is not quite correct. sync() (actually update() in the kernel) not only queues up the write requests but initiates it (in XXstrategy()). Thus the writes are completed as fast as the kernel/driver/hardware is capable of it. Furthermore, a second /bin/sync would probably just read from the buffer cache, since it was just read in from the first /bin/sync. What this means, though, is that it pays to wait a second or two after running /bin/sync to allow the hardware to do the writes (they are done asynchronously, unlike normal file I/O). I, too, run sync*3 just because I saw someone else do it. As a beginning UNIX hacker you are pounded with the idea that if you don't do a sync, every filesystem will be totally destroyed and you will have lost years of work. No wonder we are nervous and sync twice or three times. As an aside, I noticed that the 4.2BSD manual page for update(8) still carries that ol' BUGS message about how you can actually damage a filesystem by halting the CPU with update(8) running. Does anyone know if this problem is still valid for modern day DEC CPU's, buses and controllers. Dan