Voodoo Practices

[Dan Ts'o]

In article <> john at 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