telling you to type in "sync" multiple times was the old-timers way of ensuring that the first sync completed (maybe about a second) before you turned the power off, even if you were a newbie SA.
But writes are still getting added after the sync. Maybe I'm wrong but it seems like sync has to not try to sync those latecomers, because otherwise it might run forever, with new writes showing up each time it waits for current writes to sync.
Assuming the above is true, it makes sense to sync multiple times. You converge towards being fully synced. The first sync might take extra long (say 30s) because there could be tons of stuff unsynced. But the next sync should only have those 30s worth of writes to sync. Let's say that takes 5s. Now the third sync only has 5s worth of writes to sync, and that takes 1s...
This is all built on some assumptions about how sync works. But it feels like sync needs to be able to terminate & these assumptions are the only thing I can imagine that makes sure sync can ever finish, without never ending changes keeping it open.
that would have to be an awful lot of data, or a very slow drive, perhaps a floppy?
your other assumptions are sensible, to an extent. but way back when, we typically had a script that sent a message to all ttys saying "system going down in 30 seconds, please log off" - in fact ALL the other systems i used back then (Dec10, VAX, IBM 4381) did this before the sync (or whatever they did).
Good Kingstons did 5MB/sec, top of the line ones did 11MB/sec.
My example used more illustrative than real numbers. Still, 10s seems not totally uncommon, which is only 3x off.
Also I'm around 70% sure remounting system readonly does equivalent of sync & not allow more writes.
https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reb...
Still no confirm or deny on Linux.
I was at +2 and now 0 after this post rose to the top. Am I bitter? No...
That's the only way it makes sense. The caller controls when they start the sync, so they can make sure that all writes they care about have been issued by then.
But it's impossible to define a temporal ordering between writes and the time the sync completes. That's not a well-defined point in time. There's always a non-zero delay between the time the sync proper completes and the caller gets back control.