What Is The Linux fsync Command?

23 April 2026
Jonathan Aquilina - Eagle Eye T
Bash Scripting , Commands , Linux , Uncategorized

The Linux fsync topic is one of those areas that looks simple at first but becomes much more important once you care about reliability, crash safety, and data integrity.

The first thing to understand is that fsync is most commonly known in Linux as the fsync() system call, while the more familiar shell level command most users run directly is sync.

That distinction matters because the two are related, but they are not the same thing. sync(1) is documented as the command to synchronize cached writes to persistent storage, while fsync(2) is the lower level interface used to synchronize a file’s in core state with the storage device.

In practical terms, fsync() is used by applications to force modified file data and the metadata needed to retrieve it onto persistent storage. Its purpose is to reduce the risk of important data still sitting in memory buffers or cache when a system crashes or loses power.

The Linux manual is explicit that fsync() flushes both modified file data and associated metadata, and blocks until the device reports the transfer has completed.

What fsync Actually Does

When a program writes to a file on Linux, that does not always mean the data is immediately committed to disk. Linux uses caching and buffered writes to improve performance.

That is normally a good thing for speed, but it also creates a window where data may appear written from the application’s point of view while still not being fully durable on persistent storage. The sync manual even notes that persistence guarantees vary by system.

That is where fsync() comes in. It tells the operating system to flush modified data for a specific file descriptor, along with the relevant metadata, so the write is pushed out more safely. This is why fsync matters in areas such as databases, backup tooling, mail systems, VM storage, and scripts that update critical files.

fsync vs sync

A lot of Linux users searching for fsync are really thinking about sync, and that confusion is understandable.

In my post entitled What Is The Linux Sync Command & What Does It Do? is the most natural internal companion here because it covers the broader shell command many administrators will actually run manually.

The simplest way to explain the difference is this:

sync is the user facing command commonly run from the shell to synchronize cached writes to persistent storage. It can also target specific files or their containing filesystems.

fsync() is the lower level interface applications use when they need stronger guarantees for a specific open file.

fdatasync() is a related call that avoids flushing metadata unless that metadata is needed for subsequent data retrieval, which can reduce disk activity in some workloads.

That makes fsync more precise, while sync is broader and more general in day to day administration.

Why fsync Matters

If a system crashes at the wrong moment, buffered writes can become a real problem. A file may be partially updated, newly written data may never make it fully to storage, or an application may believe it saved something that was still only in cache. fsync exists to reduce that risk.

That is especially important for:

Databases

Databases often rely on durability guarantees. If a transaction is marked complete, the application needs confidence that the underlying write has actually been committed. This is exactly the kind of workload fsync() is meant to support.

Critical configuration changes

If a script overwrites a production config file and the machine crashes mid operation, you can end up with corruption, partial writes, or an inconsistent state.

That is one reason why safe scripting discipline matters. Your can read more on my post set -euo pipefail: Why This One Line Separates Fragile Scripts from Reliable Systems is a very relevant supporting read, and it is live on your site.

Storage and filesystem operations

Once you start thinking about durability, you quickly end up thinking about filesystems as well. You can read more on Ext4 vs Btrfs vs XFS vs ZFS: Which to Choose? because filesystem behavior and design affect how writes, metadata, and integrity are handled in practice. That article is also live.

One Important Detail People Miss

A key nuance with fsync() is that forcing a file’s contents to storage does not automatically mean the directory entry containing that file has also reached disk. The Linux manual states that if you need that guarantee, an explicit fsync() on a file descriptor for the directory is also required.

This is one of the reasons Linux reliability topics are often misunderstood. People tend to think “write completed” means “fully safe on disk,” but real durability is more layered than that.

Is fsync a Normal Linux Command?

For most users, not in the same way sync is. In normal Linux usage, fsync is primarily treated as a system call used by applications and utilities rather than a shell command most people type directly every day.

That is why it makes more sense to explain fsync as a durability mechanism than as a standard standalone command.

That said, some tools do expose fsyncstyle behavior through options or implementation details.

One good example is sfdisk, whose Debian man page documents --move-use-fsync, an option that uses the fsync system call after each write when moving partition data.

Performance vs Durability

There is always a trade off. Buffered writes improve speed, but stronger flush behavior improves safety. The Linux fsync(2) documentation explicitly notes that fdatasync() exists to reduce disk activity for applications that do not require all metadata to be synchronized.

That means not every workload needs the same strategy.

For temporary files or low value data, aggressive syncing may be unnecessary. For a transaction log, database journal, or important config update, it can be essential. Linux administration is often about knowing when convenience is enough and when durability must come first.

Final Thoughts

The Linux fsync topic is really about understanding what “saved” truly means.

In Linux, a completed write is not always the same thing as a durable write. That is why fsync matters. It sits at the intersection of storage, application design, scripting discipline, and system reliability.

If you want the short version:

sync is the broader shell level tool most users recognise.

fsync() is the lower level durability mechanism applications use for specific files.

If you care about crash consistency, fsync is worth understanding properly.

Call to Action

Have you ever assumed a file write was safely on disk when it actually was not?

Understanding the difference between buffered writes, sync, and fsync is one of those Linux details that can save you from painful mistakes later.

If you work with critical data, scripts, backups, or production systems, this is a concept worth mastering.

Leave your thoughts and comments down below and remember The Singularity is always watching.