block/nvme: exploring asynchronous durability notification semantics

Hi Hannes, Christoph,

thank you both for the detailed replies. They were very helpful and corrected several misconceptions on my side.

In particular, I now understand that:

- reliance on synchronous flushes is not universal and largely depends on filesystem design (e.g. ext4 vs btrfs),
- FUA already provides a per-request durability guarantee when needed,
- and that power-backed guarantees at the system level are much harder to make reliable than they may appear.

Based on your feedback, I took some time to read more about how this problem is handled in practice, especially at the filesystem and database level (e.g. journaling, WAL, group commit, batching of fsync).

It seems that the cost of durability in fsync-heavy workloads is indeed well known, but is typically addressed at higher layers rather than in the block layer or device interface.

So rather than defending my original idea, I would like to refine the question.

Is there a fundamental reason why these optimizations are handled exclusively at the filesystem / application level, instead of being exposed (or assisted) at a lower level such as the block layer or device interface?

For example, is it due to:

- lack of reliable visibility into device-internal persistence state,
- difficulty in defining correct semantics across different hardware,
- or simply that higher layers already have enough information to optimize safely (making lower-level support unnecessary)?

I realize that my earlier proposal likely underestimated the complexity involved, but I am still trying to understand whether there is a meaningful limitation at the lower layers, or if this is primarily a question of where the problem is best solved.

Thanks again for your time and for the insights — this has already been very useful for understanding how these pieces fit together.

Best regards,
Esteban