[TUHS] shutdown for pre-v7 unix

[Clem Cole]

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

>
> On Jul 16, 2014, at 8:09 PM, Dan Stromberg <drsalists at gmail.com> wrote:
>
> > On Wed, Jul 16, 2014 at 2:12 PM, Dave Horsfall <dave at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140717/95fa1fd9/attachment.html>