6 ms·

Reading the article, the headline is inaccurate/wrong: the problem is crappy SSDs (an age-old problem) that can't handle/brick under some workload presumably in

Reading the article, the headline is inaccurate/wrong: the problem is crappy SSDs (an age-old problem) that can't handle/brick under some workload presumably involving high write rates. This Windows update happens to include an application that can generate such a workload.

fifteen1506 1y ago
Sometimes people have limited amount of money available and buying a new SSD for the sake of buying them is not on top of their priority list. Sure, we can always contract a divinacy specialist to guess which hardware may fail next, but I thought the (paid) Windows testers had that job.
- whatevaa 1y ago
  Windows has paid QA these days? I thought insiders do that for free.
- gchamonlive 1y ago
  Apparently it's not wise to replace your QA testers with vibe coders, specially when your models are mediocre at best https://news.ycombinator.com/item?id=12763389 https://news.ycombinator.com/item?id=12763389
oncallthrow 1y ago
Please explain to me in precise terms how the headline is "wrong".
- dkiebd 1y ago
  SSDs bricking themselves when you write to them is not a Windows issue.
lexlambda 1y ago
Reading the article further, they do note that "A suspected memory leak in Windows’ OS-buffered cache region could be the problem.", although I concede that no source is provided for that.
rikafurude21 1y ago
Why blame the crappy SSDs when the issue seems to be that Microsoft doesnt care about their low end users and happily deploys apps which creates work loads that can literally break hardware? Even if it doesnt break your hardware, why deploy something so bloated?
- hulitu 1y ago
  > that Microsoft doesnt care about their low end users and happily deploys apps which creates work loads that can literally break hardware? Damn, i hate to defend Mickey$oft here but, if your hardware breaks under work loads, better buy a better one. Windows is not able to use all cores on a CPU properly, so if you have a workload problem, it is your hardware.
- BenjiWiebe 1y ago
  If your software can break your hardware on a normal PC (not talking industrial robots or something), your hardware is flawed.
  - wiseowise 1y ago
    Your finger can also be easily cut off by a wood cutter, doesn't mean that it has to be.
  - gchamonlive 1y ago
    While this is largely true, that's no excuse for a system such as Windows to brick SSDs like that. It's still by far the most popular operating system despite Microsoft's best efforts into enshitifying it. Windows is therefore going to be used by a wide variety of systems, including those with low grade hardware parts. So it either has to be part of windows quality control to test these low end systems or it should make it very clear about the system requirements. Either way, the problem was patched, which makes it a problem on windows side.
    - ghosty141 1y ago
      What? If your SSD is old and close to failure, you can’t blame the software pushing it over the edge. If a company sells parts that can’t handle writes that are within spec then I’m sorry you bought junk…
gchamonlive 1y ago
I'll keep using Linux then, if my crappy SSD is an excuse to use an actually functional OS, all the better. It's a win-win.
- jlokier 1y ago
  That's up to you. But if you have one of the SSD models the article is about, Linux probably won't help. It might make it worse. Linux is beautifully optimised for performance. Linux is more likely to write the same data more quickly than Windows, when an application has a large amount of data to write. So if the problem is the SSD fails when a large amount of data is written quickly but within specs, then it's likely to fail on Linux too. Unless it's a bug in the Windows driver. But it sounds from descriptions that it isn't a bug in Windows, it's a bug in the SSD that went unnoticed because not many people wrote large amounts of data quickly on systems with those SSDs. So it sounds like there may be a model-specific blacklist required in the driver, to detect particular SSDs and reduce the speed they are written to, because they fail when run at the speed they advertise to the OS. Or, alternatively, it sounds like those models may require a firmware upgrade from the SSD vendor. If either of those are required, a similar workaround will be required in the Linux driver too, to avoid the same problem as soon as someone runs a similar application on Linux. Unfortunately, even with a speed-limiting blacklist in the driver, whether in Window or Linux, those SSD models probably still corrupt data from time to time, because speed alone is unlikely to be the underlying cause of corruption. A vendor firmware update, or vendor confirmation that a specific change in the driver avoids the SSD bug, are what's required.
  - gchamonlive 1y ago
    You are saying we are going to see similar reports for Linux when using these parts? Why did it started happening after a windows update then? And why did it need a patch?
    - gruez 1y ago
      >You are saying we are going to see similar reports for Linux when using these parts? The linux install base is orders of magnitude smaller than windows, so there's less of a chance that it gets picked up by tech media. Moreover if it's really an issue with the underlying hardware itself, a more technical user base would be able to trace the issue to the actual hardware, rather than going straight to social media with "ZOMG windows update bricked my PC!" >Why did it started happening after a windows update then? Some sort of code change that changes the behavior of the drive, but is technically within spec. >And why did it need a patch? Because putting in a patch doesn't imply you're at fault. The linux kernel is filled with workarounds for crappy hardware as well. The existence of those workarounds don't imply linux was somehow at fault for those bugs.
cm2187 1y ago
The article also mentions enterprise SSDs.
wildpeaks 1y ago
The result is the same from the point of view of the end user, the hardware would have continued working without the software update.
- notanewbie 1y ago
  End user here. 4 year old laptop with original storage drive (already replaced original SSD system drive with a new one) updated and corrupted the 1TB HDD. Pulled it out of the machine (HP laptop, turns out it was a Seagate HDD) and replaced it with another SSD. Yes, this laptop was originally a Windows 10. Yes, it was upgraded to Win11 last year. Blaming the end user for the update corrupting an existing drive that has had NO ISSUES for over 4 years is about the dumbest and most condescending thing I've seen. Thanks for being absolutely no help at all, everyone but wildpeaks. The very first reply is someone who apparently went over to the FB post and spammed every comment with "CLickbait (sic) doesn't apply to anyone blah blah". Considering the giant SHOVE that Microsoft has subjected us to in the last few years to upgrade to the latest and greatest OS, you would THINK that SOMEONE would remember that a lot of those older machines that are now running Win11 should be considered. Also, anyone replying to a Windows problem with "well, you should be using Linux, too bad so sad" needs to check their attitude at the door. What an entitled life you must lead. Going back to wrestling with trying to access the now external HDD. Do I sound bitter? You're d**ed straight.
icehawk 1y ago
> the problem is crappy SSDs (an age-old problem) that can't handle/brick under some workload presumably involving high write rates which part of the article leads you to believe this?
dundarious 1y ago
What is the basis for this statement that "the problem is crappy SSDs"? From TFA: > The report speculates that this could be due to a malfunction in the drive cache subsystem. Symptoms are said to recur predictably after a system reboot, which temporarily restores drive visibility but does not address the underlying fault. Affected users are said to be consistently experiencing failure under similar workload patterns within minutes. > Further analysis has suggested that SSDs built on Phison NAND controllers especially DRAM-less models exhibit failures at lower write volumes. Reports suggest that select enterprise-grade HDDs also display comparable symptoms under intensive writes. > The issue definitely bears high similarity to the WD SN770 host memory buffer (HMB) flaw, and in this case, too, restricting or disabling HMB yields no improvement. A suspected memory leak in Windows’ OS-buffered cache region could be the problem. Speculation almost entirely revolves around the Windows disk cache subsystem. That being said, I completely disagree with most of the replies you are getting. If Intel/AMD released a CPU that exhibited faults at high instruction throughput (making good use of all execution ports, etc.) but within the advertised power limits, I would in no way blame whatever software exhibited the problem, I would blame the chip.

fifteen1506 1y ago

Sometimes people have limited amount of money available and buying a new SSD for the sake of buying them is not on top of their priority list. Sure, we can always contract a divinacy specialist to guess which hardware may fail next, but I thought the (paid) Windows testers had that job.

whatevaa 1y ago
Windows has paid QA these days? I thought insiders do that for free.
gchamonlive 1y ago
Apparently it's not wise to replace your QA testers with vibe coders, specially when your models are mediocre at best https://news.ycombinator.com/item?id=12763389 https://news.ycombinator.com/item?id=12763389

oncallthrow 1y ago

Please explain to me in precise terms how the headline is "wrong".

dkiebd 1y ago
SSDs bricking themselves when you write to them is not a Windows issue.

lexlambda 1y ago

Reading the article further, they do note that "A suspected memory leak in Windows’ OS-buffered cache region could be the problem.", although I concede that no source is provided for that.

rikafurude21 1y ago

Why blame the crappy SSDs when the issue seems to be that Microsoft doesnt care about their low end users and happily deploys apps which creates work loads that can literally break hardware? Even if it doesnt break your hardware, why deploy something so bloated?

hulitu 1y ago
> that Microsoft doesnt care about their low end users and happily deploys apps which creates work loads that can literally break hardware? Damn, i hate to defend Mickey$oft here but, if your hardware breaks under work loads, better buy a better one. Windows is not able to use all cores on a CPU properly, so if you have a workload problem, it is your hardware.
BenjiWiebe 1y ago
If your software can break your hardware on a normal PC (not talking industrial robots or something), your hardware is flawed.
- wiseowise 1y ago
  Your finger can also be easily cut off by a wood cutter, doesn't mean that it has to be.
- gchamonlive 1y ago
  While this is largely true, that's no excuse for a system such as Windows to brick SSDs like that. It's still by far the most popular operating system despite Microsoft's best efforts into enshitifying it. Windows is therefore going to be used by a wide variety of systems, including those with low grade hardware parts. So it either has to be part of windows quality control to test these low end systems or it should make it very clear about the system requirements. Either way, the problem was patched, which makes it a problem on windows side.
  - ghosty141 1y ago
    What? If your SSD is old and close to failure, you can’t blame the software pushing it over the edge. If a company sells parts that can’t handle writes that are within spec then I’m sorry you bought junk…

gchamonlive 1y ago

I'll keep using Linux then, if my crappy SSD is an excuse to use an actually functional OS, all the better. It's a win-win.

jlokier 1y ago
That's up to you. But if you have one of the SSD models the article is about, Linux probably won't help. It might make it worse. Linux is beautifully optimised for performance. Linux is more likely to write the same data more quickly than Windows, when an application has a large amount of data to write. So if the problem is the SSD fails when a large amount of data is written quickly but within specs, then it's likely to fail on Linux too. Unless it's a bug in the Windows driver. But it sounds from descriptions that it isn't a bug in Windows, it's a bug in the SSD that went unnoticed because not many people wrote large amounts of data quickly on systems with those SSDs. So it sounds like there may be a model-specific blacklist required in the driver, to detect particular SSDs and reduce the speed they are written to, because they fail when run at the speed they advertise to the OS. Or, alternatively, it sounds like those models may require a firmware upgrade from the SSD vendor. If either of those are required, a similar workaround will be required in the Linux driver too, to avoid the same problem as soon as someone runs a similar application on Linux. Unfortunately, even with a speed-limiting blacklist in the driver, whether in Window or Linux, those SSD models probably still corrupt data from time to time, because speed alone is unlikely to be the underlying cause of corruption. A vendor firmware update, or vendor confirmation that a specific change in the driver avoids the SSD bug, are what's required.
- gchamonlive 1y ago
  You are saying we are going to see similar reports for Linux when using these parts? Why did it started happening after a windows update then? And why did it need a patch?
  - gruez 1y ago
    >You are saying we are going to see similar reports for Linux when using these parts? The linux install base is orders of magnitude smaller than windows, so there's less of a chance that it gets picked up by tech media. Moreover if it's really an issue with the underlying hardware itself, a more technical user base would be able to trace the issue to the actual hardware, rather than going straight to social media with "ZOMG windows update bricked my PC!" >Why did it started happening after a windows update then? Some sort of code change that changes the behavior of the drive, but is technically within spec. >And why did it need a patch? Because putting in a patch doesn't imply you're at fault. The linux kernel is filled with workarounds for crappy hardware as well. The existence of those workarounds don't imply linux was somehow at fault for those bugs.

cm2187 1y ago

The article also mentions enterprise SSDs.

wildpeaks 1y ago

The result is the same from the point of view of the end user, the hardware would have continued working without the software update.

notanewbie 1y ago
End user here. 4 year old laptop with original storage drive (already replaced original SSD system drive with a new one) updated and corrupted the 1TB HDD. Pulled it out of the machine (HP laptop, turns out it was a Seagate HDD) and replaced it with another SSD. Yes, this laptop was originally a Windows 10. Yes, it was upgraded to Win11 last year. Blaming the end user for the update corrupting an existing drive that has had NO ISSUES for over 4 years is about the dumbest and most condescending thing I've seen. Thanks for being absolutely no help at all, everyone but wildpeaks. The very first reply is someone who apparently went over to the FB post and spammed every comment with "CLickbait (sic) doesn't apply to anyone blah blah". Considering the giant SHOVE that Microsoft has subjected us to in the last few years to upgrade to the latest and greatest OS, you would THINK that SOMEONE would remember that a lot of those older machines that are now running Win11 should be considered. Also, anyone replying to a Windows problem with "well, you should be using Linux, too bad so sad" needs to check their attitude at the door. What an entitled life you must lead. Going back to wrestling with trying to access the now external HDD. Do I sound bitter? You're d**ed straight.

icehawk 1y ago

> the problem is crappy SSDs (an age-old problem) that can't handle/brick under some workload presumably involving high write rates which part of the article leads you to believe this?

dundarious 1y ago

What is the basis for this statement that "the problem is crappy SSDs"? From TFA: > The report speculates that this could be due to a malfunction in the drive cache subsystem. Symptoms are said to recur predictably after a system reboot, which temporarily restores drive visibility but does not address the underlying fault. Affected users are said to be consistently experiencing failure under similar workload patterns within minutes. > Further analysis has suggested that SSDs built on Phison NAND controllers especially DRAM-less models exhibit failures at lower write volumes. Reports suggest that select enterprise-grade HDDs also display comparable symptoms under intensive writes. > The issue definitely bears high similarity to the WD SN770 host memory buffer (HMB) flaw, and in this case, too, restricting or disabling HMB yields no improvement. A suspected memory leak in Windows’ OS-buffered cache region could be the problem. Speculation almost entirely revolves around the Windows disk cache subsystem. That being said, I completely disagree with most of the replies you are getting. If Intel/AMD released a CPU that exhibited faults at high instruction throughput (making good use of all execution ports, etc.) but within the advertised power limits, I would in no way blame whatever software exhibited the problem, I would blame the chip.