> > The best explanation I was ever able to get for the "sync, sync, halt"
> > rule of thumb was that the extra typing gave you something to do
> > during any time it might take for the writes initiated by 'sync' to
> 
> That's not quite how I was told.  The idea is (Was?  I'm not sure if it
> is still true) that the first sync scheduled all dirty buffers to be
> written to disk.  The second sync blocked until the effects of the first

I'd be equally willing to buy that explanation. That they're both circulating
(among others) mostly proves that the behavior of sync has never quite been
specified well enough, and its implementation tends to lag behind new
developments in architecture and drivers that play havoc with its assumptions
(cf. the on-device write-back cache thread seen in this space some weeks
ago).  I bet (could be wrong) Kernighan and Pike didn't sit down and say
"let's design a sync that schedules writes but doesn't block on them, and
then blocks if issued again."  It was probably a simpler idea at first, and
then didn't get updated for some lower level scheduling change, and some
people got filesystems hosed and then somebody discovered that two syncs
would work, and somebody later may have figured out why.

But given either of the two explanations above, we would agree that sync
was supposed at least to schedule all the appropriate writes.  From this
thread I'm thinking that's no longer true, and I agree with suggestions
that it should be true.  Sure, the meaning of sync may have taken some
accidental historical hits when lower level changes were not taken into
account, but that doesn't mean we shouldn't try to preserve its useful
expected meaning when we do think about it and have the opportunity.

The earlier thread about how to handle fsync() on write-back devices
involved a strong argument from performance, but I don't think that
argument would be as strong here.  When I type sync, or my power script
executes it, I don't care much about TPS, I just want it really sync.

-Chap