News for hackers. Stuff that matters.
Re:Apple's custom NVMes are amazingly fast – if you don't ca... by garaetjjte on Thursday February 17, 2022 @03:21PM (#30378138)
Flush with other vendors at least does something as they block for some time too, just not as long as Apple.

Apple implementation is weird because actual amount of data written doesn't seem to affect flush time.

Re:Apple's custom NVMes are amazingly fast – if you don't ca... by monocasa on Thursday February 17, 2022 @04:17PM (#30378811)
On at least one drive I saw, the flush command was instead interpreted as a barrier to commands being committed to the log in controller DRAM, which could cut into parallelization, and therefore throughput, looking like a latency spike but not a flush out of the cache.
Re:Apple's custom NVMes are amazingly fast – if you don't ca... by marcan_42 on Thursday February 17, 2022 @11:12PM (#30382060)
My test is single threaded, and thus has no parallelism to begin with.
Re:Apple's custom NVMes are amazingly fast – if you don't ca... by monocasa on Thursday February 17, 2022 @11:16PM (#30382078)
The drive controller is internally parallel. The write is just a job queue submission, so the next write hits while it's still processing previous requests.
Re:Apple's custom NVMes are amazingly fast – if you don't ca... by marcan_42 on Friday February 18, 2022 @12:30AM (#30382449)
People have tested this stuff on storage devices with torture tests. Can you point at an example of a modern (directly attached) NVMe drive from a reputable vendor that cheats at this?

FWIW, macOS also has F_BARRIERFSYNC, which is still much slower than full syncs on the competition.