Honestly I don’t know. The order-of-magnitude performance difference in deferring the flush feels worth it to me if the risk is mitigated to sudden power loss.
I would think when the last of Apple’s hardware moves to ARM they’ll ensure there’s enough onboard battery to ensure the flushes happen reliably across form factors even if there’s a power cut.
If anything, now that the reason for the performance difference has been identified, I’d hope to see numbers for Linux and Windows storage access come up to par with these numbers as they go down this road too (e.g. via the NVME flush toggle mentioned in the article).
Yeah. If the same thing happens to a brand-less garbage SSD you purchased from Aliexpress it's clearly cheat and plainly malicious and incompetence, but the Apple tag certainly made us believe there is a second reason.
Trading correctness for performance without shouting at the users "YOUR DATA IS NOT SAFE WHEN YOU DO THIS" multiple times a day in a storage is benchmark-snake-oil. Period.
I’m not arguing for or against, I’m just pointing out that trading the possibility of data loss in the few seconds after a power cut for a difference of this magnitude actually makes sense in a lot of use cases.
My point above was that the same “cheat” (to use your word) could be applied to the unbranded SSD too, with similar performance gains.
I’m not giving Apple a pass for low flush performance, I’m saying there’s nothing I can see here that’s uniquely available to Apple that would prevent others from deferring flushes in the same way for similar performance gains - which would make sense in many cases.
Honestly I don’t know. The order-of-magnitude performance difference in deferring the flush feels worth it to me if the risk is mitigated to sudden power loss.
I would think when the last of Apple’s hardware moves to ARM they’ll ensure there’s enough onboard battery to ensure the flushes happen reliably across form factors even if there’s a power cut.
If anything, now that the reason for the performance difference has been identified, I’d hope to see numbers for Linux and Windows storage access come up to par with these numbers as they go down this road too (e.g. via the NVME flush toggle mentioned in the article).
Yeah. If the same thing happens to a brand-less garbage SSD you purchased from Aliexpress it's clearly cheat and plainly malicious and incompetence, but the Apple tag certainly made us believe there is a second reason.
Trading correctness for performance without shouting at the users "YOUR DATA IS NOT SAFE WHEN YOU DO THIS" multiple times a day in a storage is benchmark-snake-oil. Period.
I’m not arguing for or against, I’m just pointing out that trading the possibility of data loss in the few seconds after a power cut for a difference of this magnitude actually makes sense in a lot of use cases.
My point above was that the same “cheat” (to use your word) could be applied to the unbranded SSD too, with similar performance gains.
I’m not giving Apple a pass for low flush performance, I’m saying there’s nothing I can see here that’s uniquely available to Apple that would prevent others from deferring flushes in the same way for similar performance gains - which would make sense in many cases.
The same thing happens in POSIX, most unices, including Linux itself until recently.
So there's that.
It's rather Apple's slow drive firmware checks though, that is problematic.
>If anything, now that the reason for the performance difference has been identified
That's not the reason for the M1 performance differences (as a CPU).
Just for the disk writing (which isn't the fastest around to begin with anyway).
There's no good reason for this to be a performance tradeoff. Flushes taking this long on Apple SSDs has to be a dumb firmware performance bug.
1 reply →