> For the complete documentation index, see [llms.txt](https://mariadb.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/operating-system-optimizations/storage-io-buffering-and-persistence.md). # Storage I/O: Buffering and Persistence This page defines the I/O behavior terms that other MariaDB documentation pages use — *unbuffered I/O*, *write-through*, *persist to non-volatile storage* — and shows how each one maps to the underlying mechanism on Unix-like systems and Windows. Other pages refer here for the OS-level details rather than embedding system-specific flag names inline. ## Why This Matters The MariaDB server, and especially the [InnoDB](/docs/server/server-usage/storage-engines/innodb.md) storage engine, needs precise control over when writes actually reach non-volatile storage. The operating system normally buffers writes in memory (the *page cache*) and flushes them to disk on its own schedule. That is fast, but unsafe for a transactional database: a power loss between the application write and the OS flush would lose committed data. MariaDB therefore exposes configuration that lets administrators choose between OS-buffered performance and database-controlled durability. The configuration uses general I/O terms — buffering, write-through, persistence — that describe the behavior independent of the operating system. This page is the reference for what those terms mean and how each OS implements them. ## Unbuffered I/O **Behavior**: Reads and writes bypass the operating system's page cache. Each read fetches directly from the storage device; each write is handed to the device without keeping a copy in OS memory. **Trade-off**: Avoids "double buffering" — that is, caching the same data both in MariaDB's own buffer pool and in the OS page cache, which costs memory and CPU. The trade-off is the loss of the OS's read-ahead and write-coalescing optimizations. Unbuffered I/O is most appropriate when MariaDB itself manages most of the memory available for caching data (for example, when the InnoDB buffer pool is sized to most of system RAM). | Operating system | Underlying mechanism | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Unix-like | File opened with `O_DIRECT`. Supported on Linux, FreeBSD, NetBSD, Dragonfly BSD, Illumos / Solaris, and IBM AIX; not supported on OpenBSD or Apple macOS. | | Windows | File opened with `FILE_FLAG_NO_BUFFERING` | ## Write-Through **Behavior**: Every individual write call returns only after the storage layer has accepted the data for non-volatile storage. Equivalent to issuing a write followed by an immediate persist, on every single write. **Trade-off**: Maximum durability per write, at the cost of write latency. The application does not need to issue a separate persist call to know that data is safe. | Operating system | Underlying mechanism | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Unix-like | File opened with `O_DSYNC`. Supported on Linux, FreeBSD, NetBSD, Solaris, and IBM AIX; not supported on Dragonfly BSD (which has `O_FSYNC`, not used by MariaDB), OpenBSD, or Apple macOS. | | Windows | File opened with `FILE_FLAG_WRITE_THROUGH` | ## Persist to Non-Volatile Storage **Behavior**: After one or more buffered writes, force any data still in the OS page cache or the storage device's own write cache out to non-volatile media. The call returns only once the data is durable. **Trade-off**: Lets the application batch many writes cheaply and persist them with a single explicit call, instead of paying the durability cost on every write (as write-through does). This is the foundation of MariaDB's group-commit and binary-log durability behavior. MariaDB does not validate file access or modification timestamps anywhere, so on each platform it prefers the lighter-weight call that omits those metadata updates, falling back to the full-persist call only when the lighter one is not available. | Operating system | Underlying mechanism | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Unix-like | `fdatasync()` when available (Linux, FreeBSD, Dragonfly BSD, NetBSD, OpenBSD, Solaris, IBM AIX); `fsync()` otherwise (notably Apple macOS). | | Windows | `NtFlushBuffersFileEx()` with the `FLUSH_FLAGS_FILE_DATA_SYNC_ONLY` flag when available — documented for NTFS, and observed to work on ReFS as well. `FlushFileBuffers()` otherwise (older Windows versions, non-NTFS filesystems, or if the lighter call fails at run time). | ## See Also * [`innodb_flush_method`](/docs/server/server-usage/storage-engines/innodb/innodb-flush-method.md) — selects InnoDB's combination of buffering and persistence strategies. * [`sync_binlog`](/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md#sync_binlog) — controls how often the binary log is persisted. * [`innodb_doublewrite`](/docs/server/server-usage/storage-engines/innodb/innodb-system-variables.md#innodb_doublewrite) — InnoDB's protection against torn writes. * [Filesystem Optimizations](/docs/server/ha-and-performance/optimization-and-tuning/operating-system-optimizations/filesystem-optimizations.md) — choosing and tuning the filesystem MariaDB writes to.