Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

twitter.com

Post reply on HN
Print view View original

191–200 of 261 posts

Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

#191

Post by alias_neo »

Shekelphile wrote: post #110
loeg wrote: post #55

Earlier quoted context omitted.

Where are you seeing counterfeits? AliExpress, Ebay, Amazon?

Probably chinese sellers on all those sites. I've noticed a common thread with people who complain about counterfeits is that they're literally buying alphabet soup brand fakes from chinese FBA sellers instead of buying products directly sold by amazon or from more traditional retail channels.

> alphabet soup brand fakes from chinese FBA sellers instead of buying products directly sold by amazon

Does this actually make a difference? I remember the issue was that Amazon would bin devices together regardless if they're from some random third-party or direct sale, so you could have fakes mixed in with genuine and it was basically a lucky dip.

Is this not still the case?

Ultimately, I'd be weary of buying things like this from Amazon and as you suggest go to a more traditional retail channel instead.

Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

#193

Post by JonChesterfield »

Shekelphile wrote: post #110
loeg wrote: post #55

Earlier quoted context omitted.

Where are you seeing counterfeits? AliExpress, Ebay, Amazon?

Probably chinese sellers on all those sites. I've noticed a common thread with people who complain about counterfeits is that they're literally buying alphabet soup brand fakes from chinese FBA sellers instead of buying products directly sold by amazon or from more traditional retail channels.

Sold by amazon means "taken out of a box containing fakes and maybe real products". If that's your gamble, may as well buy the fake directly at lower cost.

Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

#194

Post by worthless-trash »

matja wrote: post #172
Dylan16807 wrote: post #78

Earlier quoted context omitted.

The current default is data=ordered, which should prevent this problem if the hardware doesn't lie. The data doesn't go in the journal, but it has to be written before the journal is committed. There was a point where ext3 defaulted to data=writeback, which can definitely give you files full of null bytes. And data=journal exists but is overkill for this situation.

> which should prevent this problem if the hardware doesn't lie. Or, one can take the ZFS approach and assume the hardware often lies :)

I do not know how zfs will overcome hardware lying. If its going to fetch data that is in the drives cache, how will it overcome the persistence problem ?

Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

#195

Post by kmxdm »

Writes are completed to the host when they land on the SSD controller, not when written to Flash. The SSD controller has to accumulate enough data to fill its write unit to Flash (the absolute minimum would be a Flash page, typically 16kB). If it waited for the write to Flash to send a completion, the latency would be unbearable. If it wrote every write to Flash as quickly as possible, it could waste much of the drive's capacity padding Flash pages. If a host tried to flush after every write to force the latter behavior, it would end up with the same problem. Non-consumer drives solve the problem with back-up capacitance. Consumer drives do not have this. Also, if the author repeated this test 10 or 100 times on each drive, I suspect that he would uncover a failure rate for each consumer drive. It's a game of chance.

Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

#196

Post by danarmak »

worthless-trash wrote: post #194
matja wrote: post #172

Earlier quoted context omitted.

> which should prevent this problem if the hardware doesn't lie. Or, one can take the ZFS approach and assume the hardware often lies :)

I do not know how zfs will overcome hardware lying. If its going to fetch data that is in the drives cache, how will it overcome the persistence problem ?

It will at the very least notice that the read data does not match the stored checksum and not return the garbage data to the application. In redundant (raidz) setups it will then read the data from another disk, and update the faulty disk. In a non-redundant setup (or if enough disks are corrupted) it will signal an IO error.

An error is preferred to silently returning garbage data!

Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

#197

Post by gumby »

kmxdm wrote: post #195

Writes are completed to the host when they land on the SSD controller, not when written to Flash. The SSD controller has to accumulate enough data to fill its write unit to Flash (the absolute minimum would be a Flash page, typically 16kB). If it waited for the write to Flash to send a completion, the latency would be unbearable. If it wrote every write to Flash as quickly as possible, it could waste much of the driv…

The whole point of explicit flush is to tell the drive that you want the write at the expense of performance. Either the drive should not accept the flush command or it should fulfill it, not lie.

(BTW this points out the crappy use of the word “performance” in computing to mean nothing but “speed”. The machine should “perform” what the user requests — if you hired someone to do a task and they didn’t do it, we’d say they failed to perform. That’s what’s going on here.)

Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

#198

Post by nolist_policy »

kmxdm wrote: post #195

Writes are completed to the host when they land on the SSD controller, not when written to Flash. The SSD controller has to accumulate enough data to fill its write unit to Flash (the absolute minimum would be a Flash page, typically 16kB). If it waited for the write to Flash to send a completion, the latency would be unbearable. If it wrote every write to Flash as quickly as possible, it could waste much of the driv…

> If a host tried to flush after every write to force the latter behavior, it would end up with the same problem.

So? No reason to break the contract that flush makes all submitted writes durable. The drive can compact space in the background.

Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

#199

Post by thargor90 »

vladvasiliu wrote: post #173
IngvarLynn wrote: post #40

There 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 updat…

That's interesting. I have a Samsung 990 pro bought on Amazon and have the random lags. I've only noticed it in the terminal, so I figured something else may be the culprit. Never went to 15 secondes, but it can be around 1s. The Samsung Magician app on Windows reports it as "genuine" and it was able to apply two firmware updates. The only thing it complains about is that I should be using PCIE 4 instead of 3, but I…

I have been able to fix these random lags by doing multiple full disk reads. The first one will take very long, because it will trigger these lags. Subsequent ones will be much better.

The leading theory I have read is that maintenance/refreshing on the ssd is not done preventative/correctly by the firmware and you need to trigger it by accessing the data.

Re: I tested four NVMe SSDs from four vendors – half lose FLUSH'd data on power loss (2022)

#200

Post by gumby »

danarmak wrote: post #196
worthless-trash wrote: post #194

Earlier quoted context omitted.

I do not know how zfs will overcome hardware lying. If its going to fetch data that is in the drives cache, how will it overcome the persistence problem ?

It will at the very least notice that the read data does not match the stored checksum and not return the garbage data to the application. In redundant (raidz) setups it will then read the data from another disk, and update the faulty disk. In a non-redundant setup (or if enough disks are corrupted) it will signal an IO error. An error is preferred to silently returning garbage data!

It can’t tell if the drive is lying to it.
Post reply on HN