2,抓紧自查smart 重点查 媒体与数据完整性错误计数 主机指令超时 编程失败计数 编程失败计数最差值 坏块计数

这个事其实就是不知道怎么情况，硬盘就卡死了或者无法访问了，这时候硬盘可能还在写，然后可能界面或者什么操作就卡住了。看到这个情况一慌，来个强制重启或者关机啥的，硬盘就报废了。

最开始是硬盘变成1MB，然后是Diskgeinus打开报错，我把硬盘拆了。接linux系统上, 又经过我的一顿操作，现在直接不认盘了，凉凉……

硬盘信息现在无法读取了。

已报废，凉凉 呵呵哒。

这个盘是没有缓存的，当然只要眼睛不瞎都能看出来。

主控上面印刷的rmc，上面印的型号是RTS5735DLQ L420ZP1 GL18AA

闪存颗粒是ADATA 上面印的60079381 530449181B 121965911A81441

这特么是什么颗粒现在也搞不清楚，估计也没法用开卡工具刷活了。

中间尝试拿镊子短接量产了几次，依然没救活，因为不知道具体的开卡参数和芯片型号，呵呵哒。凉凉，撒有哪啦。牛逼plus 。

当然这个事跟我一顿胡乱操作有很大的关系，不能怪别人。 损失不大，就当娱乐了。因为本身也是想测试一下到底ssd的可靠程度如何，所以搞了很多远超出正常使用的场景的测试，加上一些错误的操作。当然我一开始也没想到这玩意真的会挂掉。

如果你不幸遇到掉盘之类的故障,千万不要急着重启或者断电,这样很容易会造成硬盘严重损坏,就像我这样.

正确的操作是,不要理它,放在那里继续通电30分钟.或者时间更久,然后再尝试重启或者别的操作.

原理就是给主控芯片一点时间,让它看看能不能自检,自我修复. 如果断电就可能造成不可逆的损坏.

nand闪存有很多数据,这个数据是要有一个目录的,把数据当成书,目录当成书架

1. 如果你想修改书中的某一页，你不能直接在上面涂改。你必须把整本书抄写一遍，在抄写的过程中做出修改，然后把旧的书扔掉，把新的书放到一个新的空书架上。
2. 每个书架（闪存块/Block）被来回搬动书籍（写入/擦除数据）的次数是有限的，太多次之后就会损坏。

现在，操作系统来找书，它只知道一个简单的“逻辑地址”，比如“我想看第 205 号书”。它完全不知道这本书实际放在哪个物理角落。

FTL（Flash Translation Layer，闪存转换层） 就是这个图书馆里无所不知的超级图书管理员。它手里有一张巨大的索引卡（FTL 表），记录着：

逻辑地址（Logical Block Address, LBA）：读者要的“第205号书”。

物理地址（Physical Block Address, PBA）：这本书实际存放的“C区，第8排，第15个书架，第3层”。

每当操作系统要读取或写入数据时：

读数据：操作系统说“我要LBA 205的数据”，FTL查表，立刻知道数据实际在PBA (C,8,15,3)，然后去那里把数据取出来。

写数据：操作系统说“我要把新数据写到LBA 205”。FTL会做以下几件事：

1. 找一个新的空书架（空的物理页面） 来存放新数据。
2. 把新数据写进去。
3. 在索引卡（FTL表）上，把LBA 205指向这个新的物理地址。
4. 把原来旧数据所在的地址标记为“无效的、可回收的垃圾”。

这个过程就是 “写时重分配（Write-on-rewrite）” 和 “垃圾回收（Garbage Collection）” 的基础。正是FTL的存在，才让SSD能够模拟成和传统硬盘一样可以随机读写的块设备，对操作系统完美隐藏了NAND闪存不能就地覆盖写入的复杂物理特性。

FTL表不是一成不变的，它随着数据的写入而不断更新。这些更新不会每次立即永久写入闪存（那样太慢了），可能会先在DRAM缓存中操作，然后定期刷写到NAND中。如果正在刷写的过程中，或者刚更新完DRAM中的映射表但还没来及写回NAND时，突然断电，就会导致：

1,NAND中的FTL表是旧版本。

2,DRAM中的新映射表因为断电而丢失。

3,当下次通电时，SSD主控用旧的FTL表去查找数据，会发现逻辑地址指向的物理位置可能存放的是无效的旧数据，或者根本找不到数据，导致全盘数据错乱、无法识别。

SSD的主控芯片和固件是管理FTL的核心大脑。如果固件算法存在缺陷，可能在异常情况下错误地更新了FTL表，或者执行垃圾回收时发生了错误，误删了有效数据的映射关系，导致FTL逻辑混乱。

如果存储驱动程序或系统服务有Bug，这个Bug有可能导致了对SSD的写入指令流（I/O Pattern）出现异常。

1. 对FTL元数据区域的直接错误写入

这是最直接、最致命的可能性。操作系统本不应直接访问SSD上存储FTL表的“系统区块”。这个区域应由SSD主控全权管理。

驱动Bug可能错误地将用户数据或日志文件的写入操作，其逻辑地址（LBA） 指向了原本用于存放FTL元数据的物理地址。

主控执行了写入命令，用无用的用户数据覆盖了FTL表的一部分。当主控下次需要加载FTL时，发现其校验失败、结构破碎，整个盘的“地图”就丢失了，导致“掉盘”或容量识别错误（如变成1MB）。

2. 极端情况下的缓存刷新（Flush）指令风暴

现代操作系统为了确保数据安全，会定期向存储设备发送“缓存刷新”指令（如 FLUSH CACHE），要求设备将内部缓存（DRAM缓存或SRAM缓存）中的数据真正写入到NAND闪存中。

Bug可能导致系统在极短时间内疯狂发送海量的、不必要的缓存刷新指令。

对于无DRAM缓存、依赖HMB（主机内存缓冲）的SSD：其FTL映射表的一部分存放在系统内存中。频繁的刷新指令迫使主控需要不断地将映射表更新写回闪存。这个过程会极大占用主控的资源，并显著增加对存储FTL的NAND区块的写入磨损。在极端压力下，可能引发超时错误或写入失败，导致元数据损坏。

指令风暴可能打乱主固件的正常操作队列（如垃圾回收GC），引发不可预见的错误状态。

3. 触发了主控固件中潜藏的Bug（“Combination”问题）

这在软件/硬件交互中非常常见。Windows的异常I/O行为触发并放大了特定主控固件中原本处于休眠状态的缺陷。

主控固件可能没有对某种极端、非正常的写入请求（比如非常规大小的写入、对齐错误的请求）进行很好的容错处理。

bug驱动恰好发出了这种“异常请求”，主控固件在处理时发生逻辑错误，例如：

错误地更新了FTL表（记录了错误的映射关系）。

在执行垃圾回收（GC）时，误将包含有效数据的块标记为无效并擦除。

这些操作都会直接导致FTL逻辑混乱，最终崩溃。

4. 电源管理相关的Bug

SSD对突然断电非常敏感。虽然这次事件不是物理断电，但软件层面的“指令断电” 也可能造成类似效果。电源状态转换（如DIPM设备初始化电源管理）相关的Bug，导致SSD在活跃工作状态和低功耗状态之间频繁且快速地切换。

在状态切换的瞬间，如果发生I/O请求，可能会造成指令未完成就被中断。如果这个未完成的指令恰好是更新FTL元数据的操作，其结果就等同于一次“软件层面上的突然断电”，导致FTL数据不一致。

来自评论区的@松鹤 给出了一个smart图 我这里分析一下

首先我们看一下它这个06读取,显示读取了47.6TB的数据.07写入了31.6TB的数据

他这个0E是非常严重的,任何时候0E的值都不应该大于0

记录的是在读取存储的数据时，发生的无法通过内部ECC纠错算法纠正的错误累计次数。

0E出现的可能原因:

1,物理层损坏：这意味着NAND闪存颗粒的某些存储单元已经物理性退化或损坏，导致存储的电荷不稳定，无法正确读出之前写入的数据。

2,直接关联FTL：当主控读取一个页面（Page）失败时，它会触发一系列恢复机制。如果最终恢复失败，主控会：

• 将这个无法读取的页面标记为坏块。
• 从其他冗余备份中尝试恢复数据（如果支持的话）。
• 更新FTL表，将这个出错的逻辑块地址（LBA） 重新映射到备用的物理块上。
• 在这个过程中，0e 计数就会增加。

3,数据损坏风险：如果错误无法恢复，操作系统读到的就是损坏的数据。对于程序文件会导致崩溃，对于用户数据（文档、照片）会造成永久性损坏。

0E数值为 10,454 意味着什么？

1,绝对故障：任何大于0的值都是一个明确的危险信号。而 10,454 这个数字表明错误已经发生了上万次，这证明故障不是偶发的，而是持续且恶化的。

2,FTL压力巨大：FTL表正在进行大量的重映射操作来尝试掩盖这些坏块。这会导致性能下降和延迟增加。

3,濒临死亡：硬盘的NAND闪存正在大量失效。备用块（Spare Blocks）很可能即将被耗尽。一旦备用块用尽，下一次写入错误就会直接导致硬盘无法写入，甚至彻底变砖。

0F错误日志4代表什么:

0F属性的核心含义：主机指令超时计数

这个属性记录的是硬盘在响应主机（你的电脑）的指令时，发生了超时（Timeout） 错误的次数。

意味着这块硬盘在其生命周期内，已经发生过 4 次 主机命令没有在预期时间内完成的错误。

为什么会发生超时？

当主机向硬盘发送一个读写或其他命令时，主控芯片需要在规定时间内处理完毕并返回结果。如果超过这个时间，主机就会认为这次操作“超时”了。0F值增加一次。

导致超时的可能原因包括：

1. 固件 Bug：主控固件在处理某些特定指令时出现卡顿或死锁。
2. 硬件压力：主控因过热或高负载而性能下降，无法及时响应。
3. NAND 闪存问题：读取或写入NAND闪存时遇到困难（比如需要非常强的ECC纠错），导致操作耗时远超预期。这与 0e错误密切相关。

单独看 0f=4，这个数字本身并不算非常高，可能只是硬盘生涯中的几次小意外。

但是， 0e=10454 结合起来看！

• 0e(媒体与数据完整性错误)：表示“读”数据时发现了无法纠正的错误。
• 0f(主机指令超时)：表示“响应命令”时发生了延迟或失败。

这两者同时出现异常，极大地增加了问题的严重性：

0f超时很可能就是因为 0e错误引起的。过程可能是这样的：

1. 主机请求读取某个逻辑扇区的数据。
2. 主控通过FTL表找到对应的物理页面。
3. 读取该物理页面时，发现数据错误严重（0e 错误增加），需要启动复杂的纠错算法来尝试恢复数据。
4. 这个恢复过程非常耗时，导致主控无法在规定时间内响应主机。
5. 主机等不及了，记录一次 指令超时（0f 错误增加）。
6. 最后，主控要么成功恢复数据返回给主机，要么返回错误。

1. 立即备份数据：这是最高优先级的任务。这块盘的可靠性已经严重下降，随时可能完全失效。
2. 停止使用：不要再将它用于任何重要任务。
3. 监控变化：如果你暂时还需观察，可以记录下 0e和 0f 的当前值。过一段时间再查看，如果这两个值还在继续增长，那就是硬盘正在加速死亡的明确信号。

总而言之，0f值为 4 本身不算灾难，但它和 0e 错误同时出现，就像病人不仅得了重病0e，还开始出现严重的并发症0f，这无疑确认了病情的严重性。

正常的smart数据应该是什么样的

=== START OF SMART DATA SECTION ===
SMART 整体健康自检测试结果: 通过
SMART/健康信息 (NVMe 日志 0x02, NSID 0xffffffff)
严重警告:                   0x00
温度:                        27 摄氏度
可用 Spare:                    100%
可用 Spare Threshold:          10%
已使用百分比:                    1%
读取数据单元:                    98,076,866 [50.2 TB]
写入数据单元:                    28,889,068 [14.7 TB]
主机读取命令:                    217,147,442
主机写入命令:                    146,219,369
控制器繁忙时间:                  114
电源循环次数:                    348
通电小时数:                      15,594
不安全关机次数:                   152
介质和数据完整性错误:    0
错误信息日志条目:       0
警告组件温度时间:       0 
严重组件温度时间:       0
温度传感器 1:               28 摄氏度
温度传感器 2:               39 摄氏度
错误信息 (NVMe 日志 0x01, 64个条目中的16个)
                    没有记录错误
自测日志 (NVMe 日志 0x06, NSID 0xffffffff)
自测状态: 无自测进行中
No Self-tests Logged

建议赶紧自查一下硬盘smart信息! 避免潜在的数据丢失风险!

在我的评论区里，很多人都分享了他们遇到的win11更新故障和现象。但幽默的是，他们的现象各不相同，且，和我的也不一样。

我的是无论自动更新还是手动更新，下载到100%后，就会突然变为失败。

根据我的现象，我一直认为我的这个bug是可能是因为下载包的完整性检查有bug，或者安装的一个必须的初始检查步骤有bug。

总之，win11的软件质量啊……幽默。

Win11：
KB5063878、KB5063875

一开始是有日本网友发现，在安装 KB5063878 后为《赛博朋克 2077》打补丁时，发现 SSD 突然消失，并且他进一步测试发现，如果硬盘连续写入 50GB 以上数据，且 SSD 控制器使用率超过 60%，就会出现硬盘设备掉盘、SMART 信息无法读取，重启后可短暂恢复，但反复出现

搜集了部分信息，目前已经涉及到以下品牌和主控，群联主控涉及的最多

虽然目前官方没证实有这个bug，但是不怕一万只怕万一

解决方法

在Windows更新历史记录中查看自己电脑是否已经安装此补丁，安装了的话在此界面划到下方进行卸载补丁

暂停Windows更新

桌面新建一个TXT文件，输入以下代码

暂停1000周代码：

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings]
"FlightSettingsMaxPauseDays"=dword:00001b58
"PauseFeatureUpdatesStartTime"="2023-07-07T10:00:52Z"
"PauseFeatureUpdatesEndTime"="2042-09-05T09:59:52Z"
"PauseQualityUpdatesStartTime"="2023-07-07T10:00:52Z"
"PauseQualityUpdatesEndTime"="2042-09-05T09:59:52Z"
"PauseUpdatesStartTime"="2023-07-07T09:59:52Z"
"PauseUpdatesExpiryTime"="2042-09-05T09:59:52Z"

输入完成后保存，修改文件名后缀为.reg保存后运行即可以直接暂停更新1000周！

需要更新时也可以恢复

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings]
"FlightSettingsMaxPauseDays"=-
"PauseFeatureUpdatesStartTime"=-
"PauseFeatureUpdatesEndTime"=-
"PauseQualityUpdatesStartTime"=-
"PauseQualityUpdatesEndTime"=-
"PauseUpdatesStartTime"=-
"PauseUpdatesExpiryTime"=-

1. 测试得出这个MP510 960G 在什么系统下都能掉盘，跟补丁无关
2. 从现象推测疑似是热掉盘（每次掉盘时温度比较一致）
3. 看起来行为与Windows补丁版本无关（更新前后和Linux都能掉）
4. 如果2成立 怀疑原作者的重启后无法恢复是温度还没下去 主控还在保护

个人观点建议该备份备份 该更新更新

无论如何 数据无价 勤做备份 别看到我这个测试结果就不管备份了

（顺便吐槽 测试出的掉盘温度48度左右疑似保护有点太激进了

在闲鱼又买了一块未拆封的mp510 固件版本ECFM12.1

原作者声称这个型号掉盘且无法恢复

在第一步 linux大量连续读写基准测试dd urandom到盘中

写入约100G时掉盘 重启后恢复

第一次重启后写入约50G掉盘 重启后恢复

第二次重启后写入约35G掉盘 重启后恢复

所有步骤重启后都是能重新认盘的

在第二步 202507累积更新中大量读写 方式为将两个dsr1的gguf（总共72G）同盘复制

进行测试前 我加了盘上的热电偶

T1为主控 T2为正面颗粒中间

写入约70G（从u盘拷到ssd 36G +同盘36G几乎结束）时掉盘 掉盘时主控与颗粒温度都在47度左右 重启后恢复

第一次重启后写入约40G左右掉盘 掉盘时47度左右 重启后恢复

第二次重启后写入约40G掉盘 掉盘时48度左右 重启后恢复

第三步 202508累积更新中大量读写 方式同第二步

写入约90G（一次成功72G一次大约20G）时掉盘 掉盘时主控与颗粒温度都在48度左右 重启后恢复

第一次重启后写入约40G左右掉盘 掉盘时47度左右 重启后恢复

第二次重启后写入约40G左右掉盘 掉盘时48度左右 重启后恢复

根据以上测试和现象 我还是不认为掉盘和Windows更新有明确关联

并且发现了温度和掉盘的关联

明天起来看要不要剪个视频

坏消息 这个mp510是坏的 插上去啸叫 量产工具也不认

目前为止 我只见过两块phison的盘 都是坏的 计划延期了

咸鱼买的MP510到了 不知真假 计划有变 现在就开始测

主控是PS5012-E12 颗粒不知道是个啥玩意

测试平台为NUC8i7HVK 直接连接于M2 A 系统放在u盘上

计划分为三部分：

1. 基准测试： 在linux进行连续读写 观察是否有掉盘现象
2. 在24H2 2025-07累积更新(KB5062660, 26100.4770)进行连续读写 观察是否有掉盘现象
3. 在24H2 2025-08累积更新(KB5063878, 26100.4946)进行连续读写 观察是否有掉盘现象

我有块C2000 PRO 2T 很多年前遇到过个问题 这个盘上面大规模连续读写（大约200G）会掉盘 下电休息一会会恢复

感觉这个原作者的描述符合这一场景 怀疑是同款掉盘毛病 与Windows更新无关

我还没在各种渠道看到对比安装补丁前后进行测试掉盘的问题 应该会有人做的 到时候摇我一下

我自己做了验证 202506和202508（也就是出了问题的）累积更新的联芸主控ssd和sn740连续读写160g同盘复制均未复现该问题

买了一块mp510 960g 周末试着复现一下该问题

个人怀疑是phison或者其他什么盘的主控有bug 被某些奇妙Windows配置触发了

我觉得问题可能是微软一向不按业界标准做事，或者说他认为自己就是事实标准。这次为了修复驱动的安全问题，可能抄了其他系统的标准操作方式，结果让一些为了适配windows而改了标准行为的ssd主控产生了bug行为。

还没更新的赶紧去暂停更新。

已经更新的，如果还没挂盘，赶紧去卸载更新试试。

如果卸载不掉，赶紧备份重要数据，然后重装系统吧。

如果已经出现挂盘的，固态硬盘不用想数据的事情了，准备走硬盘的售后吧！机械硬盘的话，数据可能还能救下，看运气了。

现在用着win11，每次开机我都要去系统更新里面暂停更新，为什么只有几周的暂停？

就不能像手机或者电脑上其他软件一样，你推送个系统更新通知，让用户自己选择是否要更新？

说一点猜测：应该是默认的storenvme驱动有内存泄露之类的问题，导致无dram缓存的中低端ssd在内存中的hmb缓存区域损毁。这部分保存了ssd的一部分ftl表，于是轻则ftl丢失导致锁盘（重启后ftl恢复，但文件可能损坏），重则固件直接完蛋（重启也无法恢复，显示为raw。想要抢救文件的话需要重新刷固件，建议找专业维修人员比如B站up“小飞机DIY”解决）。

至于为什么是群联最遭殃，是因为采用群联主控的中低端无缓存ssd是最多的。

中高端有独立dram缓存的ssd也不一定能完全逃过一劫。文件损坏是有可能的，但因为没有hmb，内存中任何崩溃影响不了ssd本身，所以应该不会遇到ftl表或者固件损坏的问题。也就是说最坏的情况是重启后恢复，死不了。

此bug极有可能在7月可选更新（7月末发布）中就已经存在。如果能卸载补丁，建议退回到7月初或者6月底的版本。如果补丁已经固化无法卸载，可以使用第三方nvme控制器驱动（比如三星或者海力士提供的驱动）暂时代替默认的storenvme，大概率能避免此bug。