Strong Consistency commit-to-device durability and drive cache interaction

Namespace Durability in Strong Consistency Mode

Aerospike Strong Consistency (SC) mode utilizes a consensus protocol to ensure linearizability. When the commit-to-device configuration is set to true, the system is intended to force an fsync() to the storage device before acknowledging a write to the client, ensuring that acknowledged data survives an unclean shutdown.

Hardware Cache Uncertainty

The effectiveness of this durability guarantee depends heavily on the underlying hardware. While enterprise-grade SSDs with Power Loss Protection (PLP) ensure that data in the volatile write cache is flushed to non-volatile media during power failure, consumer-grade drives may report a successful sync to the OS while the data remains in a volatile buffer.

There is currently no built-in mechanism within the strong-consistency statistics to verify if a specific acknowledged write reached the physical platter/cell versus the kernel page cache or a volatile drive cache.

• How does Aerospike validate the hardware's fsync implementation to ensure commit-to-device=true provides actual durability on drives without PLP?
• Is there a method to monitor or audit whether writes are bypassing the drive's volatile cache in SC mode?