6386 shutdown: I CAN'T BELIEVE at&t was really this stupid!

[M.R.Murphy]

In article <14506 at watdragon.waterloo.edu> hjespersen at trillium.waterloo.edu (Hans Jespersen) writes:
+In article <14401 at bfmny0.UUCP> tneff at bfmny0.UUCP (Tom Neff) writes:
+ 
+>To minimize the risk from power hits and crashes, I add a root cron job
+>that performs a 'sync ; sync' every 10 minutes.  I have not been reliably
+                  ^^^^^^^^^^^  
+
+Why do people always do this? Running sync twice does nothing that
+running sync once wouldn't do. Remember that 'sync' does NOT guarantee
+that all delayed writes are actually written out to disk. It mearly
+guarantees that they are in the queue to be written as soon as possible.
+When you are at a shell prompt running

The reason that people do this comes from heeding the warning in the manual
section UPDATE(VIII) that was released 11/1/73 with Version 5 (not System V).
update did the sync every 30 seconds.

Quoting, albeit without permission, though in hope that none will complain
too bitterly,

	BUGS
		With update running, if the CPU is halted just as the sync
		is executed, a file system can be damaged. This is partially
		due to DEC hardware that writes zeros when NPR requests fail.
		A fix would be to have sync temporarily increment the system
		time by at leaset 30 seconds to trigger the execution of update.
		This would give 30 seconds grace to halt the CPU.

The entry for SYNC(II) in the same manual is similar to the entry in a System V
manual with the sentence, again quoted without permission,

	The writing, although scheduled, is not necessarily complete upon
	return from the sync.

present in the System V manual and missing in the Version 5 manual.

Since presumably the paragraph in SYNC(II) in the Version 5 manual and in
SYNC(2) in the System V manual that suggests that programs such as fsck and
df that jerk with file systems should sync, and since the manditory use of
sync before boot is stated, it probably is a good idea to sync before halt or
re-boot :-).

The reasoning for two syncs goes like this:

	1. Manually type sync. It is scheduled, but doesn't complete
	   all the important work.

	2. Shut off or halt the machine just as the really important
	   write is happening or just as some other sync occurs as a
	   result of something like the cron entry suggested above.

	3. Be real sad that the disk is corrupted.

or,

	1. sync twice with a little time between so that nothing remains
	   to be written and a shut off or halt won't interrupt a write.

+
+# sync
+# sync
+# sync
+
+usually guarantees enough time has passed (since the first sync) that
+the files were written to disk. Running
+
+# sync;sync;sync
+
+is kind of stupid since the first sync is not performed until after
+you have typed the whole line in. 
+
+-- 
+Hans Jespersen
+hjespersen at trillium.waterloo.edu
+uunet!watmath!trillium!hjespersen


Disk controllers change. System software techniques change. Old habits change,
but not so easily. If you don't type sync;sleep 3;sync after completing a big
edit and before you can back up onto something other than the one flakey disk
drive, you've probably never had some[one|thing] crash your system just before
you do the backup. And your changes are lost, and you can't remember the
brilliant technique that you used in the changes.

Some go so far as to have an entry for user "sync"" in /etc/passwd with
no password and a shell of /bin/sync just in case the system is hung so
logins of a more complicated nature can't be performed and a sync is
required/desired before pulling the plug. At least it makes you feel better.
---
Mike Murphy  Sceard Systems, Inc.  544 South Pacific St. San Marcos, CA  92069
mrm at Sceard.COM        {hp-sdd,nosc,ucsd,uunet}!sceard!mrm      +1 619 471 0655