Enquire
Linuxstorage

HOST_FLUSH and the myth of userspace disk cache control

Linux will not let userspace invent durability after the fact. Use fsync contracts.

A recurring proposal: flush “everything” from userspace after bulk load (HOST_FLUSH, exotic ioctls, blanket sync scripts) so MySQL can skip paying for durability on the write path.

That is not how Linux durability works.

The contract

Durability is agreed at write time between:

  • your fsync / fdatasync calls
  • the filesystem
  • the block layer
  • device write cache / battery-backed controllers

A later generic flush does not rewrite history for commits that never requested durability. If the application or InnoDB did not sync at commit, replaying sync(2) later cannot reconstruct lost redo.

What userspace actually has

  • fsync / fdatasync / sync — portable, correct tools
  • Mount options and barrier/flush behaviour that vary by filesystem and kernel era
  • Hardware write-cache policy (disable cache or use BBU/capacitor-backed controllers for power-fail safety)

Kernel threads and driver interfaces that do not expose a privileged “flush all device caches for this process” API will not gain one because a database wishlist asks for it.

MySQL / InnoDB knobs

# Durable commits (typical OLTP)
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

# Faster commits; acknowledged loss window on crash/power fail
innodb_flush_log_at_trx_commit = 2

Also know innodb_flush_method and whether doublewrite is on — they change how data pages hit storage, not whether a magic HOST_FLUSH saves you.

Practice

Pay for durability where you need it, at the API that means it. Pair relaxed flush settings with UPS and tested restore, not with mythology. Verify controller cache policy in hardware docs; do not infer it from MySQL feeling “fast.”