91–100 of 126 posts
Earlier quoted context omitted.
"Just" corrupting your filesystem...
Relative seriousness, both drive damage and filesystem damage are both bad but by slightly different degrees. There is more chance of being able to fix data corruption, than being able to fix a bricked drive or one with unbearable blocks.
But what's actually happening? There seems to be a lack of technical information. And why does the SSD allow this to happen? A SSD has its own onboard computer, it's not just allowing the OS to do whatever it wants. Obviously the OS can write way too much and reach the endurance limit but that should have been figured out almost instantly, with OS write stats and SMART stats.
>But what's actually happening? There seems to be a lack of technical information. That's also what I want to know. All the information on this topic seems to be just circular anecdotes like a snake eating its own tail: a bunch of anecdotal reddit posts, quoting a Tom's hardware article, that's quoting more anecdotal reddit posts, that's quoting one Japanese tweet of someone's speculation. Like how many of these SSD…
There is probably something going on. It could very well just be a bad batch of SSD controllers from one manufacturer failing.
Tomorrow, somebody will still explain to you like you're a child that Linux has hardware incompatibilities (on the computer they bought last week the day it came out), and is just not ready for prime time. They want to stick with Windows because it's safe and just works.
Tomorrow, somebody will still explain to you like you're a child that Linux has hardware incompatibilities (on the computer they bought last week the day it came out), and is just not ready for prime time. They want to stick with Windows because it's safe and just works.
I'm wondering if I should defer my full system backup on the 1st of September, as the resulting file is 300+ GB. I had a BSOD last week, 0x0000012b (FAULTY_HARDWARE_CORRUPTED_PAGE), which I've never had, and was hoping it isn't related to this update.
You might want to run memtest86+ (or the built-in equivalent from some OEMs like Dell), in my experience memory sticks sometimes go bad after being in use for a while.
That's why I don't install updates, unless and until they've been proven not to break things. I miss the old days when software was expected to work out of the box and updates, on the rare occasions when they appeared, were actually useful.
I hope you are speaking with tongue in cheek. Security is the main reason to keep current with updates. They address various “CVE” reports and go beyond to patch things not reported by CVEs.
Or if they were properly done. Example: Intel and the plundervolt vulnerability. To fix that they removed the ability for undervolting in ny laptop. If I don't use SGX there's no reason for the block. They could've restricted undervolting only when SGX is enabled but no, they had to "fix" it in the worst way possible.
That's why I don't install updates, unless and until they've been proven not to break things. I miss the old days when software was expected to work out of the box and updates, on the rare occasions when they appeared, were actually useful.
I hope you are speaking with tongue in cheek. Security is the main reason to keep current with updates. They address various “CVE” reports and go beyond to patch things not reported by CVEs.
Anyway, security updates should be decoupled from feature updates, so that people aren't hesitant to update. Otherwise, you get people who hold out because they're worried the new release is going to break all their settings and "opt-in" into all kinds of new telemetry.
Is it actually killing the SSD (SSD can no longer be used) or just corrupting the data on the SSD? It's hard to make out from all the comments and news articles.
That said, people use words with a different meaning all the time, and data corruption could fit as a failure.
Earlier quoted context omitted.
> And why does the SSD allow this to happen? A SSD has its own onboard computer, it's not just allowing the OS to do whatever it wants. If the device is DRAM-less, much of its central information (large parts of the FTL, in particular) resides in the host's RAM, where the OS could presumably touch it. If that area of RAM is _somehow_ being overwritten or out-of-sync or otherwise unreliable, you can get pretty bad cor…
no, the FTL is still in the SSD unless it's a host-managed SSD which is also operating in host-managed mode, which none of the articles have mentioned to be related to the issue
The FTL algorithm still needs one or more large tables. The driver allocates host-side memory for these tables, and the CPU on the SSD that runs the FTL has to reach out over the PCIe bus (e.g. using DMA operations) to write or read these tables.
It's an abomination that wouldn't exist in an ideal world, but in that same ideal world people wouldn't buy a crappy product because it's $5 cheaper.