iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A successful fsync() is a request to synchronize a file’s modified data and associated metadata—not a universal guarantee that every recent change will survive every crash. On Linux, durability also depends on whether the application synced the right objects in the right order and whether the filesystem, storage stack, and device honor their persistence contracts.
What does a successful fsync() actually mean?
On Linux, fsync(fd) asks the kernel to transfer modified file data and associated metadata for the open file descriptor to the storage device, and to wait until the device reports completion. The Linux manual describes the request and its limits in fsync(2).
That return value is meaningful: it says the requested synchronization completed according to the operating system and storage stack’s contract. It is not an independent inspection of the physical media, nor a proof against every software bug, hardware failure, or device that acknowledges a flush before data is actually nonvolatile. Durability is an end-to-end property, not something one system call can establish by itself.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallWhy can a file’s name disappear even if its contents were synced?
A file’s bytes and the directory entry that gives the file its name are separate pieces of state. Syncing the file does not necessarily persist the directory entry. The Linux manual states: “Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk.”
#1 Best Overall
This matters when creating, renaming, or replacing files. An application that needs a newly written file to be findable after a crash must account for both the file and the relevant directory update. The exact protocol depends on the operation and platform; syncing only the file is not a general substitute for syncing the directory.
A common Linux replacement pattern
For a same-directory replacement, a typical durability protocol is to write a temporary file, sync that file, rename it over the target, and then sync the containing directory. In code, the directory can be opened and passed to fsync() as well. The ordering matters: syncing the file before the rename addresses its contents, while syncing the directory after the rename addresses the namespace change.
If a rename moves a file between directories, both the source and destination directory updates may matter. This pattern is an illustration, not a filesystem-independent promise: applications must account for the semantics of their target operating system and filesystem, as well as errors at each step.
Does filesystem journaling make application data durable?
Not necessarily. Journaling is primarily a filesystem mechanism for recovering filesystem structures and maintaining consistency after a crash. It does not mean that every recent application write has reached persistent storage or that the application’s multi-step update is recoverable as intended.
The Linux kernel’s ext4 documentation for kernel v6.7 illustrates how behavior depends on configuration. In ext4’s data=writeback mode, data ordering relative to metadata journal commits is not preserved. The documentation also notes that delayed allocation can put older data at risk during a power loss. These are ext4-specific details, not a description of every filesystem or mount mode.
Applications therefore need their own persistence protocol where the use case requires one: for example, a journal or write-ahead log, ordered writes, and recovery logic that can determine which operations committed. A filesystem journal and an application log solve related but different problems.
How can storage caches undermine the request?
Between the system call and persistent media are filesystem code, block layers, controllers, and the device itself. A synchronization request must reach the relevant persistence boundary, and each layer must report completion honestly. If a device has a volatile write cache and acknowledges a flush while data remains only in that cache, sudden power loss can erase data the application believed was safe.
Recommended Free Tools
SQLite’s atomic-commit documentation explains this as a portability and hardware assumption. It includes historical wording that some disk controllers “lie” about data reaching the media; that is a warning about possible behavior, not evidence that all current devices do this. For a particular device, consult its manufacturer’s documentation for cache and power-loss-protection behavior.
A UPS for a home server can provide time for a controlled shutdown during mains power loss, but it cannot guarantee durable writes against an operating-system crash, filesystem bug, or storage firmware failure.
Why aren’t atomicity and durability the same?
Atomicity asks whether an operation appears all-or-nothing under a specified failure model. Durability asks whether committed state persists. An atomic write can still be lost if it was not made persistent; a durable sequence can still leave an application with a partially completed multi-step update if its protocol has no atomicity or recovery mechanism.
Linux’s ext4 atomic-write support is not a universal replacement for fsync(). The kernel documentation specifies Direct I/O and underlying hardware requirements for that facility; see ext4 atomic block writes. Its guarantees apply only within the documented feature’s constraints.
What should an application do when fsync() fails?
Check the return value. A failed synchronization means the application has not established the persistence it requested; treating the earlier write as safely committed may make recovery incorrect. The Linux manual also notes that writeback errors can be reported by later operations on file descriptors that might have written the data, so an error may not necessarily appear at the originating write().
Best Value
Do not assume that blindly retrying is always safe. The right response depends on the operation and the application’s recovery protocol: it may need to report failure, preserve the previous committed state, replay a log, or stop accepting writes until the storage problem is resolved.
A 2020 USENIX ATC study injected block I/O failures while evaluating selected workloads on ext4, XFS, and Btrfs. It found varied error reporting and application recovery behavior in those tested configurations. The results demonstrate why error handling matters; they do not predict the behavior of every application, filesystem, or device. See the USENIX ATC 2020 paper.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should you evaluate a durability claim?
Ask what failure the claim covers and which layer is responsible. A useful review checks:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →- Failure model: Does the guarantee cover a process crash, kernel crash, sudden power loss, or device failure?
- Objects persisted: Are file contents, file metadata, and directory entries all included where needed?
- Ordering and recovery: Does the application have a defined commit order and a way to recover after interruption or a reported error?
- Storage behavior: Do the operating system, controller, and device honor flushes through to nonvolatile storage? Is volatile cache protected against power loss?
- Cost: What latency or throughput trade-off does the chosen synchronization protocol impose for the workload?
There is no universal ranking of filesystems, devices, and application protocols: the guarantee depends on their specific configuration and on which failure the application must survive. The discussion here is Linux-centered; Windows, macOS, network filesystems, virtualized storage, cloud block storage, and particular device models have not been established by the cited Linux documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
