The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: clemc@ccc.com (Clem Cole)
Subject: [TUHS] shutdown for pre-v7 unix
Date: Thu, 17 Jul 2014 16:16:29 -0400	[thread overview]
Message-ID: <CAC20D2McV8R0YXLah60-YeDJQCPhPZ=nkmgfxJke9fP1zNnHaw@mail.gmail.com> (raw)
In-Reply-To: <BAACAC74-528A-4619-943E-7A1542E1CA7F@ronnatalie.com>

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>


  reply	other threads:[~2014-07-17 20:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16 18:55 Mark Longridge
2014-07-16 20:52 ` Brantley Coile
2014-07-17  2:29   ` Win Treese
2014-07-16 21:12 ` Dave Horsfall
2014-07-16 21:23   ` Dave Horsfall
2014-07-17  2:09   ` Dan Stromberg
2014-07-17 15:58     ` Warner Losh
2014-07-17 16:15       ` Clem Cole
2014-07-17 18:04         ` Ronald Natalie
2014-07-17 20:16           ` Clem Cole [this message]
2014-07-18  2:26             ` Ronald Natalie
2014-07-18  2:52               ` Tim Newsham
2014-07-18  2:58                 ` Milo Velimirovic
2014-07-18  3:42                   ` Warner Losh
2014-07-16 19:47 Noel Chiappa
2014-07-17  2:40 Norman Wilson
2014-07-17  3:55 Noel Chiappa

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='CAC20D2McV8R0YXLah60-YeDJQCPhPZ=nkmgfxJke9fP1zNnHaw@mail.gmail.com' \
    --to=clemc@ccc.com \
    /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).