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

81–90 of 261 posts

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

#81

Post by lxgr »

Filligree wrote: post #79
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 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.

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

#82

Post by Dylan16807 »

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…

Ext3 will totally let you expose yourself to those security issues. I'm not sure about ext4.

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

#84

Post by usr1106 »

RankingMember wrote: post #34
loloquwowndueo wrote: post #17

Twitter yuk, can somebody just post the names of the four tested drives and which passed/failed please?

imo hackernews should just automatically replace twitter.com with nitter.net even if just for readability without logging in's sake: https://nitter.net/xenadu02/status/1495693475584557056

We should just learn to ignore people still posting on Twitter (which is called something else now).

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

#86

Post by lxgr »

Dylan16807 wrote: post #82
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…

Ext3 will totally let you expose yourself to those security issues. I'm not sure about ext4.

Only in data=writeback mode, which is not the default in either ext3 or ext4.

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

#87

Post by wmf »

ricardobeat wrote: post #44

Misleading headline since after testing eight more drives, none more failed. 2/12 is not nearly as dramatic as “half”, and the ones that lost data are the cheap brands as one would expect.

SK Hynix is a major brand and the P31 is a great midrange SSD... except for the fact that it seemingly doesn't care about your data.

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

#88

Post by KennyBlanken »

lxgr wrote: post #77
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).

"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 the industry to be held responsible for things not working as claimed.

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

#89

Post by wmf »

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.

I wouldn't say fraud but this issue should trigger a recall.

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

#90

Post by lxgr »

throw0101b wrote: post #29
lxgr wrote: post #10

I guess it's time for `fsync_but_really_actually_sync_it_please(2)` (and the lower level equivalents in SATA, NVMe etc.)?

> (and the lower level equivalents in SATA, NVMe etc.)? This is not a technical problem that needs yet another SATA/SAS/ etc command to be standardized. It's a 'social' problem that there's no real incentives for firmware writers to tell the truth 100% of the time. The best you can hope for is if you buy a fancy-pants enterprise storage solution with compatibility lists and approved firmware versions.

Well said.

Not even OS vendors are immune to the temptations of higher performance through somewhat relaxed interpretation of interfaces: https://developer.apple.com/library/archive/documentation/Sy...

Post reply on HN