# fsync

Published articles for fsync.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## How fsync affects data durability, latency, and group commit

DevFeed: [How fsync affects data durability, latency, and group commit](<https://devfeed.tech/articles/fsync-is-the-only-thing-between-you-and-data-loss-and-it-is-slower-than-you-think-39589.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/37-fsync-durability-cost-group-commit/>)

Author: hello@ankit-rana.com

Published: 2026-08-14T00:00:00Z

Content type: article

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [data](<https://devfeed.tech/topics/data.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [NVMe](<https://devfeed.tech/topics/nvme.md>), [Replication](<https://devfeed.tech/topics/replication.md>)

Tags: [databases](<https://devfeed.tech/tags/databases.md>), [durability](<https://devfeed.tech/tags/durability.md>), [flush](<https://devfeed.tech/tags/flush.md>), [fsync](<https://devfeed.tech/tags/fsync.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [replication](<https://devfeed.tech/tags/replication.md>), [ssd](<https://devfeed.tech/tags/ssd.md>), [stack](<https://devfeed.tech/tags/stack.md>), [storage](<https://devfeed.tech/tags/storage.md>)

### AI overview

This article explains that a successful write() may leave data only in the kernel page cache, so a power loss can destroy it. It describes fsync as the operation that pushes data to the device, discusses its latency cost, and explains how group commit amortizes the synchronization barrier. It also distinguishes disk durability from replication across failure domains.

### Source excerpt

A successful write() only copies your data into the kernel page cache, where a power loss destroys it. Only fsync pushes it to the device, and because fsync is a barrier rather than a write, a system that syncs once per commit is capped at roughly one divided by the fsync latency, no matter how fast the rest of the stack is. Group commit exists to amortise that barrier, and replication solves a different failure domain than fsync does, which is why acks=all does not mean the data is on any disk.

## How fsync and Linux write paths affect data durability

DevFeed: [How fsync and Linux write paths affect data durability](<https://devfeed.tech/articles/how-safe-is-your-fsync-39635.md>)

Original publisher: [Read original article](<https://www.gauravsarma.com/posts/2025-02-20_how-safe-is-your-fsync>)

Published: 2025-02-20T00:00:00Z

Content type: tutorial

Language: en

Sources: [Gaurav Sarma's Blog](<https://devfeed.tech/sources/gaurav-sarma-s-blog.md>)

Topics: [Linux](<https://devfeed.tech/topics/linux.md>), [Filesystems](<https://devfeed.tech/topics/filesystems.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [Operating system](<https://devfeed.tech/topics/operating-system.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [filesystems](<https://devfeed.tech/tags/filesystems.md>), [fsync](<https://devfeed.tech/tags/fsync.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [linux](<https://devfeed.tech/tags/linux.md>), [operating-systems](<https://devfeed.tech/tags/operating-systems.md>), [storage](<https://devfeed.tech/tags/storage.md>)

### AI overview

This technical explainer follows a Linux write from user space through kernel buffers, the virtual file system, and storage. It describes how buffering, lazy flushing, filesystems, and sync-related options affect whether data and metadata reach disk, while noting that behavior varies by filesystem and operating system.

### Source excerpt

. [How Safe Is Your fsync...

## Threat Model Thursday: Files

DevFeed: [Threat Model Thursday: Files](<https://devfeed.tech/articles/threat-model-thursday-files-37075.md>)

Original publisher: [Read original article](<https://shostack.org/blog/tmt-files/>)

Author: Adam

Published: 2020-01-23T00:00:00Z

Content type: opinion

Language: en

Sources: [Shostack & Friends Blog](<https://devfeed.tech/sources/shostack-friends-blog.md>)

Topics: [Filesystems](<https://devfeed.tech/topics/filesystems.md>), [Security](<https://devfeed.tech/topics/security.md>), [integrity](<https://devfeed.tech/topics/integrity.md>), [Linux](<https://devfeed.tech/topics/linux.md>)

Tags: [bugs](<https://devfeed.tech/tags/bugs.md>), [filesystems](<https://devfeed.tech/tags/filesystems.md>), [fsync](<https://devfeed.tech/tags/fsync.md>), [integrity](<https://devfeed.tech/tags/integrity.md>), [linux](<https://devfeed.tech/tags/linux.md>), [mental-models](<https://devfeed.tech/tags/mental-models.md>), [postgres](<https://devfeed.tech/tags/postgres.md>)

### AI overview

This commentary examines how filesystem abstractions leak through interactions between performance, reliability, and fsync behavior. It argues that unexpected storage behavior reflects bugs and design issues rather than an operating-system tampering threat, while threat modeling remains useful for identifying security and integrity concerns.

### Source excerpt

Have you considered the idea that "Files are Fraught With Peril" lately? Maybe you should...