16 Jul
2014
16 Jul
'14
6:55 p.m.
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
16 Jul
16 Jul
8:52 p.m.
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(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
17 Jul
17 Jul
2:29 a.m.
On Jul 16, 2014, at 4:52 PM, Brantley Coile <brantley(a)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.
From MIT Project Athena, in the mid-80s (when we were
actually running 4.2BSD, but many of the Athena hackers
were well familiar with earlier versions):
When thou shuttest down the system, thou shalt
sync three times. No more, no less. Three shall
be the number of the syncing, and the number of
the syncing shall be three. Four times shalt thou
not sync, neither sync twice, except that thou
proceedest to sync a third time…
- Win
9:23 p.m.
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
17 Jul
17 Jul
2:09 a.m.
On Wed, Jul 16, 2014 at 2:12 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
On Wed, 16 Jul 2014, Mark Longridge wrote:
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.
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:58 p.m.
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:
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
On Wed, 16 Jul 2014, Mark Longridge wrote:
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.
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 
4:15 p.m.
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:
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
On Wed, Jul 16, 2014 at 2:12 PM, Dave Horsfall
<dave(a)horsfall.org>
wrote:
On Wed,
16 Jul 2014, Mark Longridge wrote:
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.
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 
6:04 p.m.
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.
8:16 p.m.
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(a)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.
18 Jul
18 Jul
2:26 a.m.
On Jul 17, 2014, at 4:16 PM, Clem Cole <clemc(a)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.
2:52 a.m.
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(a)ronnatalie.com> wrote:
On Jul 17, 2014, at 4:16 PM, Clem Cole <clemc(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
--
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com
2:58 a.m.
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(a)ronnatalie.com> wrote:
On Jul 17, 2014, at 4:16 PM, Clem Cole <clemc(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
--
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
3:42 a.m.
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(a)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(a)ronnatalie.com> wrote:
On Jul 17, 2014, at 4:16 PM, Clem Cole <clemc(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
--
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
3570
days inactive
3572
days old
13 comments
10 participants
participants (10)
-
Brantley Coile -
Clem Cole -
Dan Stromberg -
Dave Horsfall -
Mark Longridge -
Milo Velimirovic -
Ronald Natalie -
Tim Newsham -
Warner Losh -
Win Treese