Earlier quoted context omitted.
this is like blaming ftx's collapse on sloppy accounting
Yeah, I am being generous.
it's always been one of your best qualities
I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
31–40 of 261 posts
Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
#32Does advertising a product as adhering to some standard, but secretly knowing that it doesn't 100%, count as e.g. fraud? I.e., is there any established case law on the matter?
I'm thinking of this example, but also more generally USB devices, Bluetooth devices, etc.
Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
#33Earlier quoted context omitted.
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?
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.
Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
#34Twitter yuk, can somebody just post the names of the four tested drives and which passed/failed please?
imo hackernews should just automatically replace twitter.com with nitter.net even if just for readability without logging in's sake:
Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
#35The posting is from Feb 2022, nearly 2 years ago.
How is this suddenly trending on Hacker News?
Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
#36Well, yes, but which were those 2 out of 4 vendors ?
There were a few more listed deeper in the thread. Fyi, the nitter version is actually readable: https://nitter.net/xenadu02/status/1495693475584557056#m Samsung 970 Evo Plus: MZ-V7S2T0, 2021.10: Pass WD Red: WDS100T1R0C-68BDK0, 04Sept2021: Pass Crucial P2 250GB CT250P2SSD8, FW P2CR046: Pass Samsung 980 250GB MZ-V8V250, 2021/11/07: Pass WD Black SN750 1TB WDS100T1B0E, 09Jan2022: Pass WD Green SN350 240GB WDS240G20C,…
So...vendors no sane person would store valuable data on their drives were the only ones that failed. The sound of a dog biting a man...
Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
#37The posting is from Feb 2022, nearly 2 years ago. How is this suddenly trending on Hacker News?
Doesn’t take much for a story to trend. Also, it’s an interesting topic.
Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
#38[flagged]
Multiple reports in the Twitter thread that this also happens for server-grade HDDs.
Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
#39Losing flushes is obviously bad. I wonder how much perf is on the table in various scenarios when we can give up needing to flush. If you know the drive has some resilience, say, 0.5s of time it can safely writeback during, maybe you can give up flushes (in some cases). How much faster is the app then? It's be neat to see some low-cost improvements here. Obviously in most cases, just get an enterprise drive with supe…
If the write-cache is reordering requests (and it does, that's the whole point), you can't guarantee that $milliseconds will be enough unless you stop all requests, wait $milliseconds, write your commit record, wait $milliseconds, then resume requests. This is essentially re-implementing write-barriers in an ad-hoc, buggy way which requires stalling requests even longer.
Flush+FUA requires the data to be stored to non-volatile media. Capacitor-backed RAM dumping to flash is non-volatile. When a drive knows it has enough capacitor-time to finish flushing all preceding writes from the cache, it can immediately say the flush was completed. This can all be handled on the device without the software having to make guesses at how long something has to be written before it's durable.
Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)
#40There is a flood of fake SSDs currently, mostly big brands. I've recently purchased counterfeit 1TB. It passes all the tests, performance is ok, it works... except it gets episodes where ioping would be anything between 0.7 ms and 15 seconds, that is under zero load. And these are quality fakes from a physical appearance perspective. The only way I could tell mine was fake is that the official Kingston firmware update tool would not recognize this drive.