Subject: Re: Question: various bugs in sync()?
To: None <tech-kern@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-kern
Date: 01/15/1999 11:58:45
[ On Fri, January 15, 1999 at 03:35:39 (-0500), Thor Lancelot Simon wrote: ]
> Subject: Question: various bugs in sync()?
>
> 	Conclusion: sync() returns once I/O for all delayed writes has
> 	been scheduled, but not completed.  That is, it converts
> 	delayed writes into asynchronous writes, which usually
> 	complete after it exits.

In fact I've clearly observed the effect you describe on several systems
where I've seen the prompt printed long before the disks stop working.
 
> 	I guess this is the traditional semantic.

Traditional that sync() return before buffers are flushed?  Only in some
circles, I suppose.

The original reason the old Unix hacks always recommended typing
"sync<CR>" three times before powering down the system was that doing so
on a sticky old teletype machine usually took long enough that the first
command had actually taken effect and by the time you could reach for
the power switch on the cabinet beside you the disks would have really
completed their writes.  Of course back then you could clearly observe
the disk activity of a system even if you were missing either the sense
of sight or sound, so long as you were not on the wrong end of a remote
connection.

However I've used several UNIX implementation where as far as I could
tell the bug you refer to has apparently been fixed.

>       However, it
> 	doesn't agree with what the sync(8) manual page says
> 	happens,

My interpretation of sync(8) is that it does *not* disagree with the
behaviour of the system.  In fact it very clearly passes all
responsibility to what the sync(2) manual page defines.

That's not to say I think sync(8) is a good manual page.  It's full of
generic advice and platitudes -- it's not really a reference manual.  It
would do better to duplicate the first couple of sentences of the
description in the sync(2) page and then strongly recommend use of
shutdown(8) and finally close with the same BUGS section from sync(2).

>           and the behaviour is mentioned as a bug in the
> 	sync(2) manual page.
>
>       What do relevant standards require?

I don't know that the "standards" have anything to say here -- this is
something that's usually well outside the purview of standards bodies.
I don't think most even describe sync(8) [The Single UNIX Specification
Version 2 doesn't seem to].

The Single UNIX Specification does define sync(2) [though I doubt POSIX
does]:

     NAME

     sync - schedule filesystem updates

     SYNOPSIS
     
#include <unistd.h>

void sync(void);

     DESCRIPTION
     
     The sync() function causes all information in memory that updates
     file systems to be scheduled for writing out to all file systems.
     
     The writing, although scheduled, is not necessarily complete upon
     return from sync().
     
     [[ .... ]]

This definition would not necessarily conflict with the requirement in a
particular implementation that sync() return only after all buffers are
written.  I would certainly like to see NetBSD and others impose this
requirement on sync(2).

> Bug #2: data for block devices without mounted filesystems is not
> 	flushed by sync(2).
> 
> 	Because sys_sync walks the list of mounted filesystems,
> 	data for block devices is not sync()ed.

This is definitely bad.
 
-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>