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

71–80 of 261 posts

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

#71

Post by KennyBlanken »

thanhhaimai wrote: post #68
alanfranz wrote: post #58

Earlier quoted context omitted.

You can either not editorialize the title, and accept that the thread contains updates, or editorialize it and violate HN guidelines. Either choice will lead somebody to complain

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.

....except people routinely submit articles with titles edited to be clickbaity and misleading, they get upvoted, and nothing happens.

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

#72

Post by KennyBlanken »

lmm wrote: post #70
wannacboatmovie wrote: post #61

Earlier quoted context omitted.

Clearly they should only editorialize the ones that are wrong.

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

So is it the mods who are editing titles of articles to be more sensational and clickbait-y? Because this happens all the damn time, flagging does nothing, etc.

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

#73

Post by wannacboatmovie »

lmm wrote: post #70
wannacboatmovie wrote: post #61

Earlier quoted context omitted.

Clearly they should only editorialize the ones that are wrong.

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.

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

#74

Post by MBCook »

tripdout wrote: post #60

Flushing in this case is from the SSDs internal DRAM cache to the actual NAND flash?

It’s the computer telling the drive “write everything to durable storage (as opposed to some kind of in-drive cache/RAM) and tell me when it’s done”.

After that command it should be 100% safe to pull the power because everything SHOULD have been written to flash. That’s the point of the command.

It’s interesting that the drives that do it wrong still take time indicating they’re doing something.

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

#75

Post by lmm »

KennyBlanken wrote: post #72
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.

So is it the mods who are editing titles of articles to be more sensational and clickbait-y? Because this happens all the damn time, flagging does nothing, etc.

In many cases yes. I don't know if it's an automated or manual process (it seems to happen less when the US is asleep, so I suspect it's manual?), but generally if you submit a link with a title edited to be less sensational and clickbait-y it gets changed to the linked article title.

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

#76

Post by lxgr »

fulafel wrote: post #66
r1ch wrote: post #54

We shipped a shader cache in the latest release of OBS and quickly had reports come in that the cached data was invalid. After investigating, the cache files were the correct size on disk but the contents were all zero. On a journaled file system this seems like it should be impossible, so the current guess is that some users have SSDs that are ignoring flushes and experience data corruption on crash / power loss.

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…

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 disk level: We'd expect to either see no data at all, or correct data, but not zeroes or any other file's or previously written stale data.

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

#77

Post by lxgr »

CoastalCoder wrote: post #32

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

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

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

#78

Post by Dylan16807 »

fulafel wrote: post #66
r1ch wrote: post #54

We shipped a shader cache in the latest release of OBS and quickly had reports come in that the cached data was invalid. After investigating, the cache files were the correct size on disk but the contents were all zero. On a journaled file system this seems like it should be impossible, so the current guess is that some users have SSDs that are ignoring flushes and experience data corruption on crash / power loss.

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.

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

#79

Post by Filligree »

lxgr wrote: post #76
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…

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 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 is always written, and all the pointers to it also written, before the file-size gets updated.

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

#80

Post by KennyBlanken »

CoastalCoder wrote: post #32

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

Merchantability and implied fitness? You absolutely could try sue the in small claims court for damages.

For extra fun: if the box carries a trademark from a standards group, you could try adding them into the suit; use of their trademarked logo could be argued to be implied fitness, if there are standards the drive is supposed to meet to use it.

At the very least they might get tired of the expense of the expense of sending someone to defend the claim, and it would cease to be profitable to engage in this scammery.

Post reply on HN