nvme-apple: data lost on power cut despite acknowledged fsync #647

Description

I've noticed that acknowledged fsyncs are not actually sync'ed to disk at the time the fsync is acknowledged. Specifically: I'm running an etcd cluster on M1 Mac Minis and wanted to test that they came back up after power loss. As part of that testing, I cut power to one member, and then plugged it back in. After booting, that etcd member did not come back up (it panicked with tocommit [...] out of range) because its data was corrupted: log entries that had already been confirmed to other members were lost.

After noticing this issue myself and needing to rebuild the etcd member, I have used Claude to measure the issue and create a reproduction repo, linked below. I'm aware of Asahi's LLM policy, so do let me know if this is not acceptable. The LLM only helped me reproduce a real issue that I encountered.

Repro Steps

There is a detailed repro repo with steps at https://github.com/macourteau/asahi-nvme-flush-repro#reproducing.

This was tested with a fully updated fresh install of Fedora Asahi Remix:

$ uname -a
Linux prod-k8s-worker-01.prod.lan.arpa 7.1.13-402.asahi.fc44.aarch64+16k #1 SMP PREEMPT_DYNAMIC Tue Sep  8 22:03:08 UTC 2026 aarch64 GNU/Linux

There is a partial workaround for the issue (setting flush_interval=0), but perhaps this should be the default with a longer flush_interval being supported for users that need more performance, at the risk of potential data loss? Regardless, even with flush_interval=0, the SSD seems to acknowledge force-unit-access writes before they're durable, so setting flush_interval to 0 doesn't completely fix the issue.

Expected Behaviour

I would expect that acknowledged fsynced writes are not lost after a power cut.

Upload Files

No response

Please agree to the following

• I have reproduced this on Fedora Asahi Remix
• I have isolated this issue to software vendored by Asahi Linux
• I am not acting as a meat proxy for an LLM