The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] shutdown for pre-v7 unix
Date: Wed, 16 Jul 2014 23:55:59 -0400 (EDT)	[thread overview]
Message-ID: <20140717035559.0375D18C0BE@mercury.lcs.mit.edu> (raw)

    > 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



             reply	other threads:[~2014-07-17  3:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17  3:55 Noel Chiappa [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-07-17  2:40 Norman Wilson
2014-07-16 19:47 Noel Chiappa
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
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

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=20140717035559.0375D18C0BE@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    /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).