[TUHS] shutdown for pre-v7 unix

[TUHS] shutdown for pre-v7 unix

[Mark Longridge]

Hi folks,

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.

So far this has worked fairly well but I was wondering if there might
be a better way to do a shutdown on early unix.

There's a piece of code for Unix v7 that I came across for doing a shutdown:

http://www.maxhost.org/other/shutdown.c

I doesn't work on pre-v7 unix, but maybe it could be modified to work?

Mark

[TUHS] shutdown for pre-v7 unix

[Brantley Coile]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

I never used shutdown, always three sync commands.  And when you type sync, you should type three sync commands on separate lines hitting newline after each.  Only one is needed, but the extras makes sure the operators didn’t type ‘sync’ then halt the box before the buffers were flushed.


On Jul 16, 2014, at 2:55 PM, Mark Longridge <cubexyz at gmail.com> wrote:

> Hi folks,
> 
> 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.
> 
> So far this has worked fairly well but I was wondering if there might
> be a better way to do a shutdown on early unix.
> 
> There's a piece of code for Unix v7 that I came across for doing a shutdown:
> 
> http://www.maxhost.org/other/shutdown.c
> 
> I doesn't work on pre-v7 unix, but maybe it could be modified to work?
> 
> Mark
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] shutdown for pre-v7 unix

[Dave Horsfall]

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

-- Dave

[TUHS] shutdown for pre-v7 unix

[Dave Horsfall]

And on that note, there was some debate over whether it was safer to 
write-protect the RK-05s before or after hitting HALT.  Something to do 
with the hardware on the -11 waiting for something else...

This probably belongs over on PUPS :-)

-- Dave

[TUHS] shutdown for pre-v7 unix

[Dan Stromberg]

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.

[TUHS] shutdown for pre-v7 unix

[Win Treese]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]


On Jul 16, 2014, at 4:52 PM, Brantley Coile <brantley at coraid.com> wrote:

> I never used shutdown, always three sync commands.  And when you type sync, you should type three sync commands on separate lines hitting newline after each.  Only one is needed, but the extras makes sure the operators didn’t type ‘sync’ then halt the box before the buffers were flushed.

[TUHS] shutdown for pre-v7 unix

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140717/e5a7d0a4/attachment.sig>

[TUHS] shutdown for pre-v7 unix

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

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>

[TUHS] shutdown for pre-v7 unix

[Ronald Natalie]

Sync works like this:

1.   If the update-lock is already set, just return.
2.   Set the lock
3.   Write any superblocks that are marked as modified
4.   Wirte any inodes that are marked as needing update
5.   Clear the lock.
5    Write all the dirty blocks in the buffer cache (which it does at spl6());

Once it returned you should be good to go.   The only time typing multiple ones helps is if there was other activity going on while you were trying to do all this.

[TUHS] shutdown for pre-v7 unix

[Clem Cole]

I think that's is a problem in that it needs to be data blocks, inodes, and
finally superblocks to do the least damage in a crash.

It was a nice piece of work on George's part at the time.   I remember the
USENIX when he talked about it and many of us had an aha style moment.  I
remember talking to dmr about it dinner that night and he made a comment
about it being slightly embarrassing that nobody had looked it / paid
attention to it before.

Those were the days of UNIX vs RSX or UNIX vs VMS and remember one of the
prime knocks that the UNIX haters would say was that the UNIX (FS) was not
reliable.   Between Ted's fsck to replace the Xcheck() family and ghg's
kernel changes people started to stop making that claim.  UNIX was just as
good if not better than the "commercial" OSses.

Clem

The other tool that showed up around then was fsdb, but I admit I never
really felt comfortable working with it. I did it so rarely and I always
had the manual open.   But it was so easy to do more damage with it.
 Fortunately, fsck usually was good enough.



On Thu, Jul 17, 2014 at 2:04 PM, Ronald Natalie <ron at ronnatalie.com> wrote:

> Sync works like this:
>
> 1.   If the update-lock is already set, just return.
> 2.   Set the lock
> 3.   Write any superblocks that are marked as modified
> 4.   Wirte any inodes that are marked as needing update
> 5.   Clear the lock.
> 5    Write all the dirty blocks in the buffer cache (which it does at
> spl6());
>
> Once it returned you should be good to go.   The only time typing multiple
> ones helps is if there was other activity going on while you were trying to
> do all this.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140717/1e4e5fce/attachment.html>

[TUHS] shutdown for pre-v7 unix

[Ronald Natalie]

On Jul 17, 2014, at 4:16 PM, Clem Cole <clemc at ccc.com> wrote:

> I think that's is a problem in that it needs to be data blocks, inodes, and finally superblocks to do the least damage in a crash.

That is definitely the case and that was perhaps the biggest fix in BSD (and other later) was to make the file system writing more consistent so at least you didn't get trashed filesystems but at worst got some orphaned blocks that needed intervention to reclaim.

It was mandatory for operators at JHU to understand how the file system was laid out on disk, and what icheck/dcheck reported and what the options to fix things.   Link counts that were too low and dups in free should NEVER happen with an intelligently ordered set of I/O operations, but thats not what Version 6 UNIX had.   It wasn't uncommon to find several errors in the file system that would be degenerate system faults if not corrected.

But all that aside, even in those shakey days, typing sync multiple times really didn't accomplish anything and it because less useful as the file systems became more stable.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140717/94af1bbd/attachment.html>

[TUHS] shutdown for pre-v7 unix

[Tim Newsham]

One sync for the disks and two for the operator's peace of mind...

On Thu, Jul 17, 2014 at 4:26 PM, Ronald Natalie <ron at ronnatalie.com> wrote:
>
> On Jul 17, 2014, at 4:16 PM, Clem Cole <clemc at ccc.com> wrote:
>
> I think that's is a problem in that it needs to be data blocks, inodes, and
> finally superblocks to do the least damage in a crash.
>
>
> That is definitely the case and that was perhaps the biggest fix in BSD (and
> other later) was to make the file system writing more consistent so at least
> you didn't get trashed filesystems but at worst got some orphaned blocks
> that needed intervention to reclaim.
>
> It was mandatory for operators at JHU to understand how the file system was
> laid out on disk, and what icheck/dcheck reported and what the options to
> fix things.   Link counts that were too low and dups in free should NEVER
> happen with an intelligently ordered set of I/O operations, but thats not
> what Version 6 UNIX had.   It wasn't uncommon to find several errors in the
> file system that would be degenerate system faults if not corrected.
>
> But all that aside, even in those shakey days, typing sync multiple times
> really didn't accomplish anything and it because less useful as the file
> systems became more stable.
>
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>



-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

[TUHS] shutdown for pre-v7 unix

[Milo Velimirovic]

Three <mumble> for the Elven-kings under the sky,

On Jul 17, 2014, at 9:52 PM, Tim Newsham wrote:

> One sync for the disks and two for the operator's peace of mind...
> 
> On Thu, Jul 17, 2014 at 4:26 PM, Ronald Natalie <ron at ronnatalie.com> wrote:
>> 
>> On Jul 17, 2014, at 4:16 PM, Clem Cole <clemc at ccc.com> wrote:
>> 
>> I think that's is a problem in that it needs to be data blocks, inodes, and
>> finally superblocks to do the least damage in a crash.
>> 
>> 
>> That is definitely the case and that was perhaps the biggest fix in BSD (and
>> other later) was to make the file system writing more consistent so at least
>> you didn't get trashed filesystems but at worst got some orphaned blocks
>> that needed intervention to reclaim.
>> 
>> It was mandatory for operators at JHU to understand how the file system was
>> laid out on disk, and what icheck/dcheck reported and what the options to
>> fix things.   Link counts that were too low and dups in free should NEVER
>> happen with an intelligently ordered set of I/O operations, but thats not
>> what Version 6 UNIX had.   It wasn't uncommon to find several errors in the
>> file system that would be degenerate system faults if not corrected.
>> 
>> But all that aside, even in those shakey days, typing sync multiple times
>> really didn't accomplish anything and it because less useful as the file
>> systems became more stable.
>> 
>> 
>> 
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>> 
> 
> 
> 
> -- 
> Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] shutdown for pre-v7 unix

[Warner Losh]

One sync to rule them all, One sync to find them,
One sync to bring them all and in the darkness bind them
In the Land of Kernel where the buffers lie.


On Jul 17, 2014, at 8:58 PM, Milo Velimirovic <milov at cs.uwlax.edu> wrote:

> Three <mumble> for the Elven-kings under the sky,
> 
> On Jul 17, 2014, at 9:52 PM, Tim Newsham wrote:
> 
>> One sync for the disks and two for the operator's peace of mind...
>> 
>> On Thu, Jul 17, 2014 at 4:26 PM, Ronald Natalie <ron at ronnatalie.com> wrote:
>>> 
>>> On Jul 17, 2014, at 4:16 PM, Clem Cole <clemc at ccc.com> wrote:
>>> 
>>> I think that's is a problem in that it needs to be data blocks, inodes, and
>>> finally superblocks to do the least damage in a crash.
>>> 
>>> 
>>> That is definitely the case and that was perhaps the biggest fix in BSD (and
>>> other later) was to make the file system writing more consistent so at least
>>> you didn't get trashed filesystems but at worst got some orphaned blocks
>>> that needed intervention to reclaim.
>>> 
>>> It was mandatory for operators at JHU to understand how the file system was
>>> laid out on disk, and what icheck/dcheck reported and what the options to
>>> fix things.   Link counts that were too low and dups in free should NEVER
>>> happen with an intelligently ordered set of I/O operations, but thats not
>>> what Version 6 UNIX had.   It wasn't uncommon to find several errors in the
>>> file system that would be degenerate system faults if not corrected.
>>> 
>>> But all that aside, even in those shakey days, typing sync multiple times
>>> really didn't accomplish anything and it because less useful as the file
>>> systems became more stable.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> TUHS mailing list
>>> TUHS at minnie.tuhs.org
>>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>> 
>> 
>> 
>> 
>> -- 
>> Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140717/afeee592/attachment.sig>

[TUHS] shutdown for pre-v7 unix

[Noel Chiappa]

    > From: Norman Wilson <norman at oclsc.org>

    > I believe that when sync(2) returned, all unflushed I/O had been queued
    > to the device driver, but not necessarily finished

Yes. I have just looked at update() (the internal version of 'sync') again,
and it does three things: writes out super-blocks, any modified inodes, and
(finally) any cached disk blocks (in that order).

In all three cases, the code calls (either directly or indirectly) bwrite(),
the exact operation of which (wait for completion, or merely schedule the
operation) on any given buffer depends on the flag bits on that buffer.

At least one of the cases (the third), it sets the 'ASYNC' bit on the buffer,
i.e. it doesn't wait for the I/O to complete, merely schedules it. For the
first two, though, it looks like it probably waits.

    > so the second sync was just a time-filling no-op. If all the disks were
    > in view, it probably sufficed just to watch them until all the lights
    > ... had stopped blinking.

Yes. If the system is single-user, and you say 'sync', if you wait a bit for
the I/O to complete, any later syncs won't actually do anything.

I don't know of any programmatic way to make sure that all the disk I/O has
completed (although obviously one could be written); even the 'unmount' call
doesn't check to make sure all the I/O is completed (it just calls update()).
Watching the lights was as good as anything.

    > I usually typed sync three or four times myself.

I usually just type it once, wait a moment, and then halt the machine. I've
never experienced disk corruption from so doing.

With modern ginormous disk caches, you might have to wait more than a moment,
but we're talking older machines here...

	Noel

[TUHS] shutdown for pre-v7 unix

[Norman Wilson]

After a day and an evening of fighting with modern hardware,
the modern tangle that passes for UNIX nowadays, and modern
e-merchandising, I am too lazy to go look up the details.

But as I remember it, two syncs was indeed probably enough.
I believe that when sync(2) returned, all unflushed I/O had
been queued to the device driver, but not necessarily finished,
so the second sync was just a time-filling no-op.  If all the
disks were in view, it probably sufficed just to watch them
until all the lights (little incandescent bulbs in those days,
not LEDs) had stopped blinking.

I usually typed sync three or four times myself.  It gave me
a comfortable feeling (the opposite of a syncing feeling, I
suppose).  I still occasionally type `sync' to the shell as
a sort of comfort word while thinking about what I'm going
to do next.  Old habits die hard.

(sync; sync; sync)

Norman Wilson
Toronto ON

[TUHS] shutdown for pre-v7 unix

[Noel Chiappa]

    > From: Mark Longridge <cubexyz at gmail.com>

    > I was wondering if there might be a better way to do a shutdown on
    > early unix.

Not really; I don't seem to recall our having one on the MIT V6 machine.

(We did add a 'reboot' system call so we could reboot the machine without
having to take the elevator up to the machine room [the console was on our
floor, and the reboot() call just jumped into the hardware bootstrap], but in
the source it doesn't even bother to do an update(). Well, I should't say
that: I only have the source for the kernel, which doesn't; I don't at the
moment have access to the source for the rest of the system - although I do
have some full dump tapes, once I can work out how to read them. Anyway, so
maybe the user command for rebooting the system did a sync() first.)

I suppose you could set the switch register to 173030 and send a 'kill -1 1',
which IIRC kills of all shells except the one on the console, but somehow
I doubt you're running multi-user anyway... :-)

	Noel