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

91–100 of 261 posts

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

#91

Post by lxgr »

KennyBlanken wrote: post #88
lxgr wrote: post #77

Earlier quoted context omitted.

Not a lawyer, but I doubt it – otherwise you might have a case against Intel and AMD regarding Spectre and Meltdown? It might be a different story if the spec was intentionally violated, though (rather than incidentally, i.e. due to an idea that should have been transparent/indistinguishable externally but didn't work out).

"Oops we didn't mean to do that" isn't a defense from liability for product not doing what you told the purchaser it would. It's their responsibility to do develop the product correctly, do QA, and if a defect is found, advise customers or stop selling the defective goods. The greatest scam the computer industry pulled was convincing people that computers are magical, unpredictable devices that are too complex for th…

To be fair, I’m not even sure if the majority of consumers would prefer a “power outage safe” SSD that is however significantly slower over the alternative.

I do agree that there should be transparency, though: Label it “turbo mode”, add a big warning sticker (and ideally a way to opt out of it via software or hardware), but don’t just pretend to be able to have the cake and eat it too.

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

#92

Post by Filligree »

lxgr wrote: post #81
Filligree wrote: post #79

Earlier quoted context omitted.

The file isn't stored contiguously on disk, so that would depend on the implementation of the filesystem. Perhaps the size of the file can be changed, without extents necessarily being allocated to cover the new size? I seem to vaguely recall an issue like that, for ext4 in particular. Of course it's possible in general for any filesystem that supports holes, but I don't think we can necessarily assume that the data…

At least for ext4 and actually written data (i.e. not ftruncate’d files), I believe zeroes should really not occur. Both extents and the file size are metadata as far as I understand, which would be atomically updated through the journal. Data can be written before metadata (in data=ordered mode): > All data are forced directly out to the main file system prior to its metadata being committed to the journal.

Is data=ordered the default?

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

#93

Post by Tarball10 »

throw0101b wrote: post #28
sashk wrote: post #19

This is (2022). Wondering if anything changed since the original tests...

> Wondering if anything changed since the original tests... You're wondering if firmware writers lie to layers higher up in the stack? I think it's a 100% certainly that there's drive firmware that lies. There's a reason why many vendors have compatibility lists, approved firmware versions, and even their "own" (rebranded from an OEM) drives that you have to buy if you want official support (and it's not entirely a m…

I'm curious whether any of the brands which failed this test owned up to the issue and released firmware updates.

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

#94

Post by schainks »

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…

If you dig at the vendor data stored on the drive firmware, fakes are easy to spot. Model numbers, vendor ID, and serial numbers will be zero’d out or not conforming to manufacturer spec.

I purchased a bunch of fake kingston SD cards in China that worked well enough for the price, but crapped out within a year of mild use. I didn’t lose data. It was as if one day they worked. Then one day they were fried.

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

#95

Post by Dylan16807 »

wannacboatmovie wrote: post #73
lmm wrote: post #70

Earlier quoted context omitted.

That doesn't help, HN mods still "correct" it back to the wrong title even in that case.

That was sarcasm, as what's "wrong" is often subjective and up to interpretation.

And it's often not.

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

#96

Post by wannacboatmovie »

Dylan16807 wrote: post #95
wannacboatmovie wrote: post #73

Earlier quoted context omitted.

That was sarcasm, as what's "wrong" is often subjective and up to interpretation.

And it's often not.

Then it gets flagged and removed. The end.

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

#98

Post by Dylan16807 »

wannacboatmovie wrote: post #96
Dylan16807 wrote: post #95

Earlier quoted context omitted.

And it's often not.

Then it gets flagged and removed. The end.

No it doesn't. Good stories with bad titles almost always stay up.

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

#99

Post by charleshn »

Dylan16807 wrote: post #78
fulafel wrote: post #66

Earlier quoted context omitted.

I think this is typical behaviour with ext4 on Linux, if the application doesn't do fsync/fdatasync to flush the data to disk. Depending on mount options, ext4fs does metadata journaling ensuring the FS itself is not borked, but not data journaling which would safeguard the file contents in event of unclean shutdown with pending writes in the caches. The same phenomenon is at play when people complain that their log…

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.

It's likely because of delayed allocations (delalloc): https://issuetracker.google.com/issues/172227346#comment6

because the only guarantee which data=ordered provides is the security guarantee that stale data won't be revealed.

Yes, it's bad and breaks prefix append consistency, and does not match the documentation...

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

#100

Post by hurryer »

supersour wrote: post #45
jauntywundrkind wrote: post #25

Losing 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…

Performance gains wouldn’t be that large as enterprise SSDs already have internal capacitors to flush pending writes to NAND. During typical usage the flash controller is constantly journaling LBA to physical addresses in the background, so that the entire logical to physical table isn’t lost when the drive loses power. With a larger capacitor you could potentially remove this background process and instead flush the…

You could gain much more by coalescing repeated writes to the same address - database scenarios for example
Post reply on HN