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@bsdimp.com> wrote:

On Jul 16, 2014, at 8:09 PM, Dan Stromberg <drsalists@gmail.com> wrote:

> On Wed, Jul 16, 2014 at 2:12 PM, Dave Horsfall <dave@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@minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs