> 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/operating-system-optimizations/storage-io-buffering-and-persistence.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.