[dale_glass]

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.

[Sesse__]

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

[dark-star]

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

[gruez]

No, some SSDs use host memory buffer (HMB) to cache FTL tables. If the FTL cache gets corrupted, and that causes critical data to be overwritten, that could brick the SSD. For instance, if the FTL table was corrupted in such a way where a page for a random file is mapped to the page for the SSD's FTL (or other critical data), and the OS/user tries to write to that random file.

[adithyassekhar]

Isn't that a huge flaw?

[Telaneo]

Yes, which is why they're cheap(er). It's better than the alternative of using flash instead of going out to system RAM, but DRAM-less SSDs are still the cheap option; HMB is a mitigation, and not a complete fix.

[pjdesno]

The FTL executes on the SSD controller, which (on a DRAM-less controller) has limited on-chip SRAM and no DRAM. In contrast, a controller for more expensive SSDs which will require an external on-SSD DRAM chip of 1+GB.

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.

[pjdesno]

One of the Japanese sites has a list of SSDs that people have observed the problem on - most of them seem to be dramless, especially if "Phison PS5012-E12" is an error. (PS5012-E12S is the dramless version)

Then again, I think dramless SSDs represent a large fraction of the consumer SSD market, so they'd probably be well-represented no matter what causes the issue.

Finally, I'll point out that there's a lot of nonsense about DRAMless SSDs on the internet - e.g. Google shows this snippet from r/hardware: "Top answer: DRAM on the drive benefits writes, not reads. Gaming is extremely read-heavy, and reads are..."

FTL stands for flash TRANSLATION layer - it needs to translate from a logical disk address to a real location on the flash chip, and every time you write a logical block that real location changes, because you can't overwrite data in flash. (you have to wait and then erase a huge group of blocks - i.e. garbage collection)

If you put the translation table in on-SSD DRAM, it's real fast, but gets huge for a modern SSD (1+GB per TB of SSD). If you put all of it on flash - well, that's one reason thumb drives are so slow. I believe most DRAM-full consumer SSDs nowadays keep their translation tables in flash, but use a bunch of DRAM to cache as much as they can, and use the rest of their DRAM for write buffering.

DRAMless controllers put those tables in host memory, although I'd bet they still treat it as a cache and put the full table in flash. I can't imagine them using it as a write buffer; instead I'm guessing when they DMA a block from the host, they buffer 512B or so on-chip to compute ECC, then send those chunks directly to the flash chips.

There's a lot of guesswork here - I don't have engineering-level access to SSD vendors, and it's been a decade since I've put a logic analyzer on an SSD and done any reverse-engineering; SSDs are far more complicated today. If anyone has some hard facts they can share, I'd appreciate it.

[rasz]

I dont buy this. There are plenty of dramless SATA SSDs which should be impossible if your description was correct, not to mention DRAMless drives working just fine inside USB-NVME enclosures.

>but gets huge for a modern SSD (1+GB per TB of SSD)

except most drives allocate 64MB thru HMB. Do you know of any NVME drives that steal Gigabytes of ram? Afaik Windows limits HMB to ~200MB?

>Finally, I'll point out that there's a lot of nonsense about DRAMless SSDs on the internet

FTL doesnt need all that ram. Ram on drives _is_ used for caching writes, or more specifically reordering and grouping small writes to efficiently fill whole NAND pages preventing fragmentation that destroys endurance and write speed.

[dijit]

but isn’t it the case that SATA devices must receive AT commands to the disk controller while NVMe is mapped directly to the CPU?

Surely that distinction would make one more vulnerable to corruption than the other?

[Hilift]

It is not published yet on the Microsoft update page (https://support.microsoft.com/KB/5063878). And it only applies to Windows 11 24 H2.

https://learn.microsoft.com/en-us/answers/questions/5536733/...

[FirmwareBurner]

>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 deaths can actually be pinned on this update, and how much of this is just "Havana syndrome" of people's SSDs dying for whatever other reason, then they hear about this hubbub in the news and then they go on reddit and say "OMG mine too", then clickbait journalists pick up on it, and round and round we go, further reinforcing the FUD, but without any actual technical analysis to verify.

[firesteelrain]

Agree; any truth to the fact that this is push back for Windows 10 EOL?

[uyzstvqs]

Right. It could just be the usual suspects of misinformation (Reddit, click-hungry "journalists", certain YouTube/Tiktok creators) amplifying each other in a circle. Just like that "16 billion passwords data leak" earlier this year.

There is probably something going on. It could very well just be a bad batch of SSD controllers from one manufacturer failing.

[firesteelrain]

Or some weird conspiracy

[TiredOfLife]

> But what's actually happening?

Publications need clicks, videos need watches, people need upvotes