Live data from Hacker News

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

twitter.com

241–250 of 261 posts

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

#241
post #233
post #217

Earlier quoted context omitted.

Yeah, but then you have a write amplification problem. Padding is write amplification from the start, and then GC is invoked many more times than it otherwise would be. There is a fundamental problem with (truly) flushing an IO that is smaller than the media write unit. It will cause problems if "abused." The SSD either needs to take on the cost of mitigation (e.g. caps) or it needs some way to provide hints to the h…

I'm curious what the real cost of power protection is for the manufacturer. Adding caps or a bit of backup power seems like it _should_ be a fairly cheap compromise to maintain performance without lying about persistence

define 'cheap'?

You already have the device shipped to you under $40 with packaging, shipping from China, to the distributor, to you; with a profit at the every step.

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

#242

Earlier quoted context omitted.

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!

The "zeroed-out file" problem is not about firmware lying though, it is about applications using fsync() wrongly or not at all. Look up the O_PONIES controversy. Sure, due to their COW nature zfs and btrfs provide better behavior despite broken applications. But you can't solve persistence in the face of lying firmware. Even thought zfs has some enhancements to not corrupt itself on such drives, if you run for exampl…

"Renaming a file should always happen-after pending writes to that file" is not a big pony. I think it's a reasonable request even in the absence of fsync.

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

#243
post #215

Earlier quoted context omitted.

The politics are all that are left; it's impossible to use Twitter and not participate on some level. For example, Twitter is now called X. Surely they noticed that.

>For example, Twitter is now called X. Surely they noticed that. So what?

So the claim that people using Twitter are largely unaware of the substantial changes is an inaccurate one.

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

#244

Earlier quoted context omitted.

Then you are still part of the problem. Besides, if you're trying to reach the people who remain on Twitter, that says a decent amount about you.

This kind of rhetoric had a good run, but you should understand it is now (solidly) a net loss in persuasion.

The attempt is not persuasion, but alienation. This is the fate of people who behave as he does, and I believe will contribute (to the extent any one person can) in deterrence of others from trying to normalize continued Twitter usage in light of its antisemitic shift in tone.

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

#245

Earlier quoted context omitted.

The "zeroed-out file" problem is not about firmware lying though, it is about applications using fsync() wrongly or not at all. Look up the O_PONIES controversy. Sure, due to their COW nature zfs and btrfs provide better behavior despite broken applications. But you can't solve persistence in the face of lying firmware. Even thought zfs has some enhancements to not corrupt itself on such drives, if you run for exampl…

"Renaming a file should always happen-after pending writes to that file" is not a big pony. I think it's a reasonable request even in the absence of fsync.

Well, for one rename() is not always meant to be durable. It can also be used for IPC, for example some mail servers use it to move mails between queues. Flushing before every rename is unexpected in that situation.

Fun fact: rename() is atomic with respect to running applications per POSIX, that the on-disk rename is also atomic is only incidental.

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

#246

Earlier quoted context omitted.

This kind of rhetoric had a good run, but you should understand it is now (solidly) a net loss in persuasion.

The attempt is not persuasion, but alienation. This is the fate of people who behave as he does, and I believe will contribute (to the extent any one person can) in deterrence of others from trying to normalize continued Twitter usage in light of its antisemitic shift in tone.

Alienation from what? People who uncritically parrot fabrications and propaganda on HN?

THAT is what shouldn't be "normalized".

But since you brought it up, of all the indicators of societal descent over the last 7-10 years, the shift away from critical analysis and open dialogue to soviet-level information control and behavior/thought policing is most troubling.

I use Twitter daily because it's the only platform where I have a chance to hear the whole truth on a given subject, usually assembled from multiple sources. I follow a lot of actual leftists as well as the conservatives and liberals-in-exile that make up the modern "right".

I don't know that I follow anyone with whom I agree on every topic, and that's as it should be IMO. Even when I strongly disagree, I'm grateful for the freedom to hear and evaluate these voices.

And while I'm reluctant to engage with your "argument", I'll say that I've seen a handful of antisemitic posts over 10+ years on Twitter, none recently. I have seen a fair amount of anti-Israel and anti-Zionist content in the last six weeks, consistently from those on the left and consistent with what I've seen in demonstrations around the world.

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

#247

Earlier quoted context omitted.

The attempt is not persuasion, but alienation. This is the fate of people who behave as he does, and I believe will contribute (to the extent any one person can) in deterrence of others from trying to normalize continued Twitter usage in light of its antisemitic shift in tone.

Alienation from what? People who uncritically parrot fabrications and propaganda on HN? THAT is what shouldn't be "normalized". But since you brought it up, of all the indicators of societal descent over the last 7-10 years, the shift away from critical analysis and open dialogue to soviet-level information control and behavior/thought policing is most troubling. I use Twitter daily because it's the only platform whe…

The continued use of Twitter ought to be met with disdain by anyone with a modicum of integrity. It is each person’s duty to make that clear to those who seem to lack the ability to self regulate, morally.

You don’t get to support a hateful platform consequence free.

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

#248

Under long term heavy duty, I've routinely seen cheap modern platter outperform cheap brand name NVME. There's some cost cutting somewhere. The NVMEs can't seem to sustain throughput. It's been pretty disappointing to move I/O bound workloads over and not see notable improvements. The magnitude of data I'm talking about is 500-~3000GB I've only got two NVME machines for what I'm doing so I'll gladly accept that it's…

>Under long term heavy duty, I've routinely seen cheap modern platter outperform cheap brand name NVME.

Saw this happen with previous job. I upgraded several Windows devices too Windows 10 and the fastest PC was a Dell desktop with a HDD.

Midrange to lower-mid laptop coupled with low-end SSD's.

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

#249

Earlier quoted context omitted.

"Renaming a file should always happen-after pending writes to that file" is not a big pony. I think it's a reasonable request even in the absence of fsync.

Well, for one rename() is not always meant to be durable. It can also be used for IPC, for example some mail servers use it to move mails between queues. Flushing before every rename is unexpected in that situation. Fun fact: rename() is atomic with respect to running applications per POSIX, that the on-disk rename is also atomic is only incidental.

I'm not suggesting flushing for rename. If a file write and a rename happen shortly before power loss, and neither goes through, that's fine.

With this rule, three outcomes are acceptable: both occur, or neither occur, or just the file write happens. The unacceptable outcome is that just the rename happens.

("file write" here could mean a single write, or an open-write-close sequence, it doesn't particularly matter and I don't want to dig through old discussions in too much detail)

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

#250
post #233

Earlier quoted context omitted.

I'm curious what the real cost of power protection is for the manufacturer. Adding caps or a bit of backup power seems like it _should_ be a fairly cheap compromise to maintain performance without lying about persistence

define 'cheap'? You already have the device shipped to you under $40 with packaging, shipping from China, to the distributor, to you; with a profit at the every step.

$1-5

I'd gladly pay a few bucks extra for a drive that doesn't delete my data when the power fails

Post reply on HN