We're talking about scenarios where the drives report (untruthfully) that the data has been committed to non-volatile storage _before_ the power is removed
Not scenarios where the data is in the cache when the power drops and the drive is expected to write out the cache with internal power alone.
The second scenario is what's standard in enterprise class drives used with RAID controllers, the controller reports 'committed' to the OS and _then_ commits the data, it can do this because the path to nonvoltatile storage downstream of the controller has redundant power (the raid controller has a battery backup and the disks have their own battery backups, as well as control logic that guarantees data in the cache makes it to nonvolatile if the power drops out)
The first scenario is for consumer disks, they don't report 'committed' until the data is actually committed. That makes them a whole assload slower. (Unless they lie.)
Looking up the definitions of write-back vs write-thru caching will help you out here
The Flush command shall commit data and metadata associated with the specified namespace(s) to non-volatile media. The flush applies to all commands completed prior to the submission of the Flush command.
No. One is a lie. The other is an attempt at fault tolerance. The later will not claim something that isn’t true, but it will try to do what you want, as a user, as a nice gesture.
We're talking about scenarios where the drives report (untruthfully) that the data has been committed to non-volatile storage _before_ the power is removed
Not scenarios where the data is in the cache when the power drops and the drive is expected to write out the cache with internal power alone.
Aren't those the same scenario?
The second scenario is what's standard in enterprise class drives used with RAID controllers, the controller reports 'committed' to the OS and _then_ commits the data, it can do this because the path to nonvoltatile storage downstream of the controller has redundant power (the raid controller has a battery backup and the disks have their own battery backups, as well as control logic that guarantees data in the cache makes it to nonvolatile if the power drops out)
The first scenario is for consumer disks, they don't report 'committed' until the data is actually committed. That makes them a whole assload slower. (Unless they lie.)
Looking up the definitions of write-back vs write-thru caching will help you out here
From the MVMe 1.3 spec:
6.8 Flush command
The Flush command shall commit data and metadata associated with the specified namespace(s) to non-volatile media. The flush applies to all commands completed prior to the submission of the Flush command.
No. One is a lie. The other is an attempt at fault tolerance. The later will not claim something that isn’t true, but it will try to do what you want, as a user, as a nice gesture.