Is there truth to the philosophy that you should sync; sync; sync; sync?

Question

When I was first introduced to Linux, working at Cisco Systems in 2000, I was taught the merits of the sync command, used to flush buffers to disk to prevent filesystem corruption / data loss. I was told not only by coworkers there, but by friends in college to always run sync "a few" or "a bunch" of times, that is, maybe 5 - 10 times, instead of just once.

I've continued this habit ever since, but, is there any merit to this? Has anyone else ever heard this? And most importantly, can anyone provide good rationale / empirical evidence for/against the idea that you need to run sync more than once for it to be effective?

Answer 1

I heard it (sorry, I forget where) as typing the sync command three times (as in: S Y N C Return, wait for the prompt, repeat, repeat). I also read that the origin was a particular system where it would take a couple of seconds for the disk to finish flushing its buffers, even after it had told the operating system everything was fine. Typing the command twice more gave the disk enough time to settle. It seems that over the years, the purpose was forgotten, and the advice was abbreviated as sync; sync; sync which wouldn't have had the desired effect (since the disk had reported the “all clear”, the second and third syncs would complete instantly and the prompt would come back too early).

I have never heard of a system where multiple sync operations have any use, and I am highly skeptical any exist. I consider this an urban legend. On the other hand, I find it highly believable that there would be systems where you should wait a couple of seconds after sync'ing and before powering down.

Googling leads to a few independent concurring analyses, e.g. The Legend of sync. See also Is execution of sync(8) still required before shutting down linux?.

Answer 2

Old-timer here. Back in the glory days of TAPE, 3 rapid sync's in a row was a way to tell the TAPE controllers to not just un-link/unspool the tape-stream, but to rewind it as well, i.e. set the FD/rw-head to 0.

"sync;sync;sync" was really only used, productively, by those of us who cut our teeth with TAPE-based Unix's, i.e. apps whose files were mounted on /var/spool, the cheapest storage possible at the time. ;)

The MIPS Risc/OS operator manuals have a page on this ..

Answer 3

There were certainly older UNIX systems for which it was safer to sync more than once, but not all on one command line as "sync; sync; sync". In the mid-80s, this became distilled to:

When thou shuttest down the system, thou shalt sync three times. No more, no less. Three shall be the number of the syncing, and the number of the syncing shall be three. Four times shalt thou not sync, neither sync twice, except that thou proceedest to sync a third time...

I don't really know where the three times came from, except maybe that it was fun. But the word on the street to do it twice. Not as "sync; sync", but as two separate lines on the shell.

Back in the days of, say, V7 UNIX, file system repair wasn't much fun. You had to do it by hand, knowing a lot about how the filesystem worked and the idiosyncrasies of programs like dcheck, ncheck, and icheck. fsck, if you had it, wasn't always something you would trust.

This is starting to sound like a "we walked through the snow uphill both ways" story. Well, we didn't have fancy commands like reboot or shutdown. When you wanted to reboot the system, you synced the filesystem with sync, and then you hit Ctrl-P on the console to halt it.

When the sync command exited, the kernel had scheduled the sync, but not all the buffers (including the all-important filesystem superblock) had necessarily made it to the disk. So it was pretty easy to run sync and then halt things before it was safe.

Running sync again was an easy thing to do, took up the time, and had a certain intuitive appeal without having to understand it all, or deal with vague instructions like "count to 10" or something like that.

There was even a BUG section on the V7 man page for update also said:

With update running, if the CPU is halted just as the sync is executed, a file system can be damaged. This is partially due to DEC hardware that writes zeros when NPR requests fail. A fix would be to have sync(1) temporarily increment the system time by at least 30 seconds to trigger the execution of update. This would give 30 seconds grace to halt the CPU.

(which, by the way, was the very last thing in Volume 1 of the V7 manuals)

Over time, the filesystem tools and the programs for shutting down and rebooting systems got better to avoid dealing with this. Folklore, voodoo, and system magic enter into it when the system behaves mysteriously. Syncing twice made it much less likely that you'd have to get out the bit tweezers to put your filesystem back together, so it became part of the ritual. Once you've done it a bunch of times, you do it without thinking. Then someone notices and asks why. And the answer is something like, "Always done it that way. It's safer."

I won't claim that this is authoritative, and I might be wrong about some of the details. But I think it's pretty close to the origin.