I've read information about the use of sync command in Linux and how it works. But I'm unable to understand when I really should use it in files and I don't find practical examples.

For example, the command sync --data file.txt synchronizes the file data of this one, but I don't find an useful example about when I should use it and how that command is working.

Maybe is there a tool for monitoring those changes or what do I have to do for checking the effects of that command?

  • 2
    You as a user should not use sync. Just tell the system you are going to remove the drive (unmount) and it will sync for you. Jun 16 at 16:04
  • 3
    In the old days, not unmounting a drive properly (typically by removing power as removable disks were rare) caused it to be in an inconsistent state needing repairing before it could be mounted. I've witnessed this process taking 15 minutes or more on a Sun3 server. Fortunately journaling file systems have made this much, much rarer. Jun 16 at 16:07
  • 1
    Thank you a lot @ThorbjørnRavnAndersen. With all this information I will be more calm about that uses of that command. Thanks for your time! Jun 16 at 21:13
  • 1
    While journaling filesysstems keep metadata intact, meaning they do not need a repair (fsck), they will sitll happily lose user data on power outages or random disconnects. sync will ensure the data is on stable storage. Jun 17 at 14:37
  • @RememberMonica thanks for your answer. All info is useful for me, I learn more and more. Jun 19 at 19:43

3 Answers 3


From the sync manpage:

The kernel keeps data in memory to avoid doing (relatively slow) disk reads and writes. This improves performance, but if the computer crashes, data may be lost or the file system corrupted as a result. sync ensures that everything in memory is written to disk.

sync is automatically called before unmounting a volume, rebooting, or shutting down a system.

To answer your question: you call sync whenever you want to be sure that data is written to disk. It is usually not necessary to do this explicitly for local drives, but it won't hurt doing so.

  • 1
    Thank you very much! This information is very important for me as the other answers for solving my dude. Thanks for your time! Jun 16 at 21:14

Imagine you have a file on the NFS which you append on one computer in small chunks, like character by character or line by line, and read on another computer.

Program on one side did a write into the file, and then you check if it was changed on another computer. It did not change, because change was buffered. It was simply not reached the server yet. And nobody knows when the system will decide to actually send it.

When you call sync you force it to flush the buffer now.

  • 1
    Thanks a lot! I guess with this example and the other ones might be enough to solve my doubt. Thanks for your time! Jun 16 at 21:14

I/O in Linux is done to the Virtual File System (VFS). The VFS caches data structures from the various types of filesystem (ext?/XFS/BTFS, NFS, COW, FUSE etc). This means that any process I/O can use a common interface. Having the filesystem structure in memory also makes directory and inode lookups far faster than going to disk each time. Reads may still be held up whilst the data is retrieved, but writes will simply move the data into buffers, update the VFS and return.¹ A buffer which contains modified data is called a "dirty" buffer and is written out to disk by the system at a time of its choosing. "Clean" buffers contain a cache of information that is identical to the on-disk copy, so they can be deleted at any time.

Using sync forces the system to write out the dirty buffers, and not return until they mave been safely moved off the system. As "dr_" mentions, this must be done prior to a dismount. Once a dirty buffer has been written out, it remains in the memory as a clean buffer until such time as the system needs more memory for another purpose.

There is one point to bear in mind however; any external cache is unknown to the system and so sync may not be totally safe. NFS is a case in point, once the data has been transmitted to the remote system then the local machine will release the buffers. The remote machine may not have yet written the data to disk, so needs to be handled seperately. Another case is the use of external RAID controllers. Again sync will ensure the data has reached the RAID controller, but cannot know that the RAID controller has actually written it to disk.

The short answer is that on modern systems you don't normally need to use sync. However, if you have reason to believe that some part of the filesystem may become unavailable, then syncing is a wise precaution. For example, prior to doing any changes with LVM it is good practice to sync just in case there is a failure. Likewise, a sync prior to adjusting the network is advisable (if you have NFS or similar), as it would be before moving a system or doing any work on the power.

¹Unless the file was opened with O_SYNC or similar.

  • 1
    All this information is very useful, now I can understand more about this and not be worried because of I was unable to understand. Thank you a lot and thanks for your time! Jun 16 at 21:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.