The Unix Heritage Society mailing list
 help / color / Atom feed
* [TUHS] reboot(2) system call
@ 2020-07-27 18:57 Warner Losh
  2020-07-28  0:36 ` Clem Cole
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Warner Losh @ 2020-07-27 18:57 UTC (permalink / raw)
  To: TUHS main list


[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

I've done some research for a friend about when the reboot() system call
was added, and how it related to the sync, sync, sync dance.

https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html

may be of interest. Please do let me know if I've gotten something wrong...

Warner

[-- Attachment #2: Type: text/html, Size: 481 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] reboot(2) system call
  2020-07-27 18:57 [TUHS] reboot(2) system call Warner Losh
@ 2020-07-28  0:36 ` Clem Cole
  2020-07-28  4:06 ` Dave Horsfall
  2020-07-28 13:11 ` Jaap Akkerhuis
  2 siblings, 0 replies; 5+ messages in thread
From: Clem Cole @ 2020-07-28  0:36 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list


[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

Warner - awesome.  I would add a few things that were sort of in the story,
although not directly.

The primary difference between 4.0 and 4.1 was originally a political push
with Stanford trying to get VMS as the official OS for Arpa and Joy
countering with BSD claiming it was within epsilon of VMS and in some cases
faster.  The performance was the biggest of the Stanford complaints which
Bill fixed with a much a carefully placed assembler.  But IIRC, one of the
other issues was "UNIX is unreliable" and file system corrupt was tossed
out as an example of the same [The lack of real/complete Fortran compiler
was never corrected, but I remember that was one of the other reasons
given.  But it was one of the reasons why a couple of UCB compiler folks
worked on improving F77 and building dbx, although it was never in the same
league as VMS's compiler or any of the many DEC debuggers].

Anyway, after 4.0 came out, Goble released the 'Purdue file system fixes'.
 When V6-4.1BSD Unix crashed, the OS was noted for leaving a possible
corrupted file system (this was why tjk wrote fsck of course for V6 years
before).  George really spent time analyzing the order that different
writes were done *i.e.* making sure the data, inodes, superblock were
updated in the right order.  This cut down file system corruption after a
system crash.  He also had a way to force the buffer cache to be cleared
properly and part of that was that George had implemented reboot
independently of Joy and I think before Bill.

Certainly by 4.1B when McKussick's new FS was being folded into the kernel,
Joy had pulled the original file system write order changes from Purdue.
He may have done that as part of 4.1 "FASTVAX" work and before he explored
reboot.

The point is that sync, reboot, and file system block write ordering was
all mixed together.


On Mon, Jul 27, 2020 at 3:01 PM Warner Losh <imp@bsdimp.com> wrote:

> I've done some research for a friend about when the reboot() system call
> was added, and how it related to the sync, sync, sync dance.
>
> https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html
>
> may be of interest. Please do let me know if I've gotten something wrong...
>
> Warner
>

[-- Attachment #2: Type: text/html, Size: 3400 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] reboot(2) system call
  2020-07-27 18:57 [TUHS] reboot(2) system call Warner Losh
  2020-07-28  0:36 ` Clem Cole
@ 2020-07-28  4:06 ` Dave Horsfall
  2020-07-28 16:35   ` Win Treese
  2020-07-28 13:11 ` Jaap Akkerhuis
  2 siblings, 1 reply; 5+ messages in thread
From: Dave Horsfall @ 2020-07-28  4:06 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society


[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On Mon, 27 Jul 2020, Warner Losh wrote:

> I've done some research for a friend about when the reboot() system call 
> was added, and how it related to the sync, sync, sync dance. 
> https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html
> 
> may be of interest. Please do let me know if I've gotten 
> something wrong...

Seems OK to me; I was taught never to use "sync; sync; sync" for precisely 
those reasons (the buffers may not have time to flush etc, as "sync" 
merely schedules the I/O, not cause it.

-- Dave

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] reboot(2) system call
  2020-07-27 18:57 [TUHS] reboot(2) system call Warner Losh
  2020-07-28  0:36 ` Clem Cole
  2020-07-28  4:06 ` Dave Horsfall
@ 2020-07-28 13:11 ` Jaap Akkerhuis
  2 siblings, 0 replies; 5+ messages in thread
From: Jaap Akkerhuis @ 2020-07-28 13:11 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list



> On Jul 27, 2020, at 20:57, Warner Losh <imp@bsdimp.com> wrote:
> 
> I've done some research for a friend about when the reboot() system call was added, and how it related to the sync, sync, sync dance.

I remember that Piet Beertema (CWI) added a reboot command to our
unix V7 on the 11/45.  I just asked him and he said that it he did
it because he was tired to walk to the computer room.  It was way
more work then he at first expected.

Whether this was picked op by the Berkeley people he doesn't know,
but it could be.

	jaap


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] reboot(2) system call
  2020-07-28  4:06 ` Dave Horsfall
@ 2020-07-28 16:35   ` Win Treese
  0 siblings, 0 replies; 5+ messages in thread
From: Win Treese @ 2020-07-28 16:35 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society



> On Jul 28, 2020, at 12:06 AM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Mon, 27 Jul 2020, Warner Losh wrote:
> 
>> I've done some research for a friend about when the reboot() system call was added, and how it related to the sync, sync, sync dance. https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html
>> may be of interest. Please do let me know if I've gotten something wrong...
> 
> Seems OK to me; I was taught never to use "sync; sync; sync" for precisely those reasons (the buffers may not have time to flush etc, as "sync" merely schedules the I/O, not cause it.

This was summarized at MIT’s Project Athena in the mid-80s as:

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. Five is right out.

- Win



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-27 18:57 [TUHS] reboot(2) system call Warner Losh
2020-07-28  0:36 ` Clem Cole
2020-07-28  4:06 ` Dave Horsfall
2020-07-28 16:35   ` Win Treese
2020-07-28 13:11 ` Jaap Akkerhuis

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git