When is /bin/sync ever useful in modern linux?

Question

I'm curious why /bin/sync exists. I understand what it does, why paging happens and why it's important that an operating system sync. However, I'm still failing to see when calling /bin/sync is useful.

It seems to me that Linux must already sync whenever anything important is going to happen (such as before a shutdown, the lack of which in proto-Linux lead to the sync; sync; sync; myth). If Linux is going to be reliable, and we all seem to believe it is, then I must assume it's going to ensure blocks are written to the FS before it runs a command that would harm the OS without a sync.

The sync(8) man page suggests that sync be run when a program is going to close in an improper manner. I sort of see this, though I think only a very tiny number of programs would have reason to use sync (and wait around to make sure the suggestion worked), but wouldn't be able to close through a cleaner method that lets the OS sync for them.

In any case sync(8) is not the same as the /bin/sync binary. I think I must be missing a situation where the binary is useful? The only use case I've seen is running it right before making a call to mem to free up more memory and perhaps give a slightly better idea of you 'available' memory. It would be useful if you somehow realized your computer was going to explode and had just enough time to type sync before it happened perhaps, but no one is doing that by hand, instead of some watchdog program calling sync(8).

Are there other advantages to the binary I'm missing?

Answer 1

The sync utility is a trivial wrapper around the sync system call.

You don't need to call it explicitly before shutting down the computer… because the shutdown scripts do it for you! Actually, that's not necessary in most cases, because unmounting a filesystem, or switching it to read-only, flushes the data of that filesystem to the disk, and the shutdown scripts do that. Calling sync is a belts-and-braces thing, in case something goes wrong and a process somehow survives the shutdown sequence and prevents unmounting.

sync is also called at the next-to-last stage of a suspend or hibernation sequence, just before powering off the hardware. Here there's no alternative, something has to say “write all data to disk now”.

Another time when sync is useful is before doing something that has a risk of causing a crash, e.g. trying out an experimental driver.

Calling sync before a program crashes is useless. sync handles data in buffers between the programs and the storage media; it doesn't do anything to data that a program hasn't saved to a file.

Calling sync is also useless when examining available memory, since it doesn't affect available memory. While it does free write buffers for reclamation, it doesn't actually free those buffers — they'll be freed when the kernel needs to allocate memory for something else, in the meantime they stay around as cache.

Answer 2

Perhaps you know sync is useful when coping some large data to a slow drive. Just to ensure that everything is written to the external drive before pulling it out !

Answer 3

"history of sync" is a tough thing to google for ;-) A totally uninformed guess is that at least one legitimate use is for kernel developers making changes to the sync(2) system call to test. They need a way to invoke the syscall that's a little more convenient than halting or umounting a filesystem?

Answer 4

I'm still failing to see when calling /bin/sync is useful.

Most of the time it's now no longer necessary.

the sync; sync; sync myth

Actually, it was sync, sync, haltsys as three separately entered commands. Back in ancient (!) times the sync command did not block, but it merely triggered a request to the kernel to flush I/O to the disk. Generally, the time taken to type the second sync and then the haltsys would be sufficient for the data to have been flushed, so that at the point the system halted the data would have all been written. Later systems used telinit 0 or shutdown -h now to incorporate scripts that performed the sync on the administrator's behalf.

If Linux is going to be reliable, and we all seem to believe it is, then I must assume it's going to ensure blocks are written to the FS before it runs a command that would harm the OS without a sync.

This is certainly the case when writing through a filesystem; the umount command blocks until all data has been flushed to the underlying layer. Where this is the physical device all is good. What I don't know is how that expectation maps through (say) LUKS, LVM, RAID, and disk firmware through to the physical storage medium.

Where you can clearly see that a sync is required is when writing directly to slow media such as a USB device. Consider a 4GB image being written to the USB device /dev/sdX

cat 4GBimage.dat >/dev/sdX

This might take 30 seconds or a few minutes; it doesn't matter. What does matter is that the file is large enough that the command will complete significantly before the data has all been written to the device. (The joys of decent disk buffer caching.)

sync

On a Linux-based system this will (almost always) block until the data has been completely written through the USB interface to the device. A slightly longer pause, say incurred by entering sync once more, is usually sufficient to ensure the data has been written by the device firmware to its non-volatile storage.