The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Warner Losh <imp@bsdimp.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] reboot(2) system call
Date: Mon, 27 Jul 2020 20:36:33 -0400	[thread overview]
Message-ID: <CAC20D2MRjwE8QacxG33j5NaecLki1D1NR5d26XT3ib4BYX=-yQ@mail.gmail.com> (raw)
In-Reply-To: <CANCZdfosFGpBKw0wOx9nYgAWpeVNuRd-h6Nu5PLgZyyCuezZKA@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2020-07-28  0:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 18:57 Warner Losh
2020-07-28  0:36 ` Clem Cole [this message]
2020-07-28  4:06 ` Dave Horsfall
2020-07-28 16:35   ` Win Treese
2020-07-28 13:11 ` Jaap Akkerhuis
2021-01-27  6:01 ` Greg A. Woods
2021-01-30 22:27   ` Dave Horsfall
2021-01-30 22:31     ` Larry McVoy
2021-01-30 22:37       ` Warner Losh
2021-02-02  2:20     ` Greg A. Woods
2021-02-02  2:30       ` Warner Losh
2021-02-02 20:30         ` Greg A. Woods
2021-02-02  3:35       ` Dave Horsfall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2MRjwE8QacxG33j5NaecLki1D1NR5d26XT3ib4BYX=-yQ@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=imp@bsdimp.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).