Does sync(8) really flush everything? Lost writes with journaled SU after sync+power cycle

[Bruce Evans]

On Fri, 12 Apr 2013, Kevin Day wrote:

> On Apr 11, 2013, at 1:30 AM, Bruce Evans <brde at optusnet.com.au> wrote:
>>
>> sync(2) only schedules all writing of all modified buffers to disk.  Its
>> ...
>>
>> sync(8) is just a wrapper around sync(2).  One that doesn't even check
>> ...
>
> And on the flip side, the man page for syncer says:
>
> It is possible on some systems that a sync(2) occurring simultaneously with a crash may cause file system damage.  See fsck(8).

That is not useful.  It was copied from update(8) to update(4misplaced)
and then to syncer(4misplaced).  It should go without saying that a
crash may cause file system damage irrrespective of whether it occurs
simultaneously with sync(2).  Apart from that: back in 1996 when these
words in update(4) were written, all syncs were done by update(8) calling
sync(2).  With the syncer daemon, crashes may also occur concurrently with
syncer daemon activity, and that and not sync(2) became ths most common
source of crashes with syncs.  I thing these words are just a hint about
the bug that panic() calls sync().  Back in 1996, there was little locking
for sync against itself (perhaps it could deadlock).  Now there is lots of
locking for normal sync activity (e.g., sync(2) vs the syncer daemon).  I
don't know how this acts in panic() but guess that it doesn't really work.
So crashes may cause file system damage, but this has little to do with
sync(2) or even the syncer daemon (the sync() in panic() either has to
blow away all locks so that it can complete, or possibly deadlock.  If
it blows away all locks then it may cause damage directly, and if it
deadlocks then you cause the damage use reset or power cycling).

Of course, nothing about this can be seen in fsck(8).  Now there are many
foofs_fsck(8)'s where the things to be seen would have been moved to if
there were any.

> ...
> I understand that sync(8) returns immediately, I guess my confusion is that calling sync(8) doesn't seem to cause *any* writes to happen.
>
> I can have the system completely idle (absolutely no processes running that could cause any filesystem activity), call sync(8), and watching gstat(8) can see no write activity happen at all, even waiting 10+ seconds afterwards, where as "mount -u -o ro -f /" causes an instant flurry of writes to happen. My understanding was that even though sync returned immediately, flushing would also start immediately, and leave the system in a safe point, at least until another write happens.

I thought that you got the flurry of writes from sync() too, but they took
10+ seconds.  Perhaps an fs bug.

Bruce