But if you look through at the FS code of everything until after Gobble
worked on 4.1 & did the reordering work, unless you were careful with the
syncs, it was easy to have a corrupted FS. Ted's fsck(1) program made
cleaned up of corrupted FS much easier. But it was really ghg's work that
got the kernel right. When Kirk's BSD FFS was done (aka UFS) and went
into 4.1A (maybe B) you needed the Purdue mods if you wanted to have a 4.1
or V7 that could reasonable survive a power hit without FS damage.
It funny, I still type: sync<cr>sync<cr>sync<cr> before I type
reboot<cr>
it was burned into the ROMs in the fingers so long ago. My CS major
daughter once asked me my I type that ;-)
Clem
On Thu, Jul 17, 2014 at 11:58 AM, Warner Losh <imp(a)bsdimp.com> wrote:
On Jul 16, 2014, at 8:09 PM, Dan Stromberg <drsalists(a)gmail.com> wrote:
On Wed, Jul 16, 2014 at 2:12 PM, Dave Horsfall
<dave(a)horsfall.org>
wrote:
On Wed,
16 Jul 2014, Mark Longridge wrote:
I've been typing sync;sync at the shell
prompt then hitting ctrl-e to
get out of simh to shutdown v5 and v6 unix.
The "correct" way used to be:
sync
sync
sync
3 sync's was net.wisdom for a long time, but some discussions in the
Linux mailing lists suggested that 2 was enough all along.
The first schedules all dirty buffers to be flushed to disk.
The second does the same, but to provide an ordering guarantee,
doesn't return until the dirty buffers from the first are finished.
Hence the 2.
But I'm a relative newcomer to *ix - I didn't get involved until SunOS 4.
But it wasn’t about the ordering…
The reason three syncs were recommended was that you needed time to pass
to flush the buffers, and some early versions would only schedule the I/O
and not wait for it to actually complete before returning. Later versions
waited, but by then the disks had buffers of their own that would get
missed up if you didn’t wait a smidge before turning them off. So what the
second two syncs really accomplished was the passage of time before you did
anything stupid.
I’m not so sure about the “ordering guarantee” logic presented in that
thread. There’s no “barrier” that the first sync puts in that the second
sync waits for. Earlier discussions have suggested the first sync flushes
all the dirty blocks and sent out the superblock marked dirty as well. The
second sync would see no I/O has happened and send out the superblock
clean. And the third sync was because of {lots of theories here}, but
mostly was for the passage of time to keep the rule simple.
Warner
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs