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

221–230 of 261 posts

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

#221

Post by devnullbrain »

alanfranz wrote: post #69
thanhhaimai wrote: post #68

Earlier quoted context omitted.

It's clear from the guidelines: https://news.ycombinator.com/item?id=38365934#38368867 Specifically: use the original title, then express your view as a top level comment. If people agree with it, the comment is naturally voted up.

Yes, and the OP did abide by HN guidelines. But GGP implied that the title was misleading; but it was the original title! So, what to do if the original title is misleading? Admittedly this is a twitter thread, so no "actual title" exists.

>So, what to do if the original title is misleading?

Complain about it in a comment so that people who don't click the link are aware it's misleading. It's not attacking OP.

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

#222

Post by gumby »

kmxdm wrote: post #206
gumby wrote: post #197

Earlier quoted context omitted.

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…

The more dire problem is the case where the drive runs out of physical capacity before logical capacity. If the host flushes data that is smaller than the physical write unit of the SSD, capacity is lost to padding (if the SSD honors every Flush). A "reasonable" amount of Flush would not make too much of a difference, but a pathological case like flush-after-every-4k would cause the SSD to run out of space prematurel…

If it can’t honor the flush it should return an error.

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

#223

Post by worthless-trash »

gumby wrote: post #200
danarmak wrote: post #196

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!

It can’t tell if the drive is lying to it.

This was my theory too, its not going to help in -these- situations. I can't see how.

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

#224

Post by lxgr »

colanderman wrote: post #220
lxgr wrote: post #76

Earlier quoted context omitted.

I don't think that's how it works: Flushing metadata before data would be a security concern (consider e.g. the metadata change of increasing a file's length due to an append before the data change itself), so file systems usually only ever do the opposite, which is safe. Getting back zeroes after a metadata sync (which must follow a data sync) would accordingly be an indication of something weird having happened at…

The file's size could have been set by the application before copying data to it. This will result in a file which reads all zeroes. Or if it were a hardware ordering fault, remember that SSD TRIM is typically used by modern filesystems to reclaim unused space. TRIMmed blocks read as zero.

> The file's size could have been set by the application before copying data to it. This will result in a file which reads all zeroes.

Hm, is that a common approach? I thought applications mostly use fallocate(2) for that if it's for performance reasons, which does not change the nominal file size.

Actually allocating zeroes sounds like it could be quite inefficient and confusing, but then again, fallocate is not portable POSIX.

> Or if it were a hardware ordering fault

That's what I suspect might be going on here.

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

#225

Post by lxgr »

Filligree wrote: post #92
lxgr wrote: post #81

Earlier quoted context omitted.

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?

As far as I can tell it's always been on both ext3 and ext4, yes.

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

#226

Post by CaptWillard »

WendyTheWillow wrote: post #146
andybak wrote: post #117

Earlier quoted context omitted.

I'm still posting on Twitter because the people I'm trying to reach are still there and the alternatives never materialised.

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.

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

#227

Post by schleyreuth »

pleoxy wrote: post #57

If you need PLP use an enterprise drive. That's what they're for.

If stuck with consumer drives, you can add cheap PLP via riser cards that have a supercapacitor. Here's a post on the TrueNAS forums that tested one out.[1]

[1] https://www.truenas.com/community/threads/x4-pcie-to-nvme-ad...

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

#229

Post by CobaltFire »

arglebargle123 wrote: post #189

Meanwhile I'm over here jamming Micron 7450 pros into my work laptop for better sync write performance. I have very little trust in consumer flash these days after seeing the firmware shortcuts and stealth hardware replacements manufacturers resort to to cut costs.

Have a solid vendor for these that isn't insanely priced (for home use)? The last couple I tried to buy they sent 7300's and tried to buy me off with a small refund (eBay).

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

#230

Post by fulafel »

charleshn wrote: post #99
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.

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...

For more context, that's a comment from one of the ext4 main authors, Ted Ts'o. the other subsequent comment from him spells out the case more but sadly no spelled out NUL byte origin story I spotted from skimming.
Post reply on HN