不知各位有没有和我一样单独分了一个NTFS分区用来存储文件的（之前想的是以备万一，方便Windows系统访问）。

如果你正在使用NTFS分区存储文件，请尽量避免在该分区进行大量的读写操作，否则容易发生掉盘意外。

我刚才在 NTFS 分区中创建了一个项目，WorkBuddy 正在里面写项目代码时，电脑屏幕突然就黑屏提示没有引导设备了（我的是Redmi笔记本），由于当时我没有一直看着电脑屏幕，还以为是deepin突然自动重启了，但为啥没有引导设备了？我尝试手动将电脑再次重启，进入启动菜单选项，发现可引导项为空（全空，没有一个引导设备）。

想着可能是 WorkBuddy 写代码时可能把 deepin 的引导给弄坏了（美好的幻想），于是插上启动U盘，准备进入deepin的 Live 环境中查看硬盘分区中的文件是否还存在（毕竟里面有好几个花了大量时间和词元做的项目），结果选择系统语言后，就直接提示我硬盘空间不足无法安装系统。然后我知道，完蛋了，我的硬盘可能坏了。关机抽根烟冷静一下（开玩笑的，我不抽烟😂，但真的担心 ），过了一会再次按下开机键，(@ο@) 哇～，美好的系统启动项居然自动恢复了。

赶紧进系统准备看看情况，但进入系统后，感觉一切正常(谁的系统还没意外重启过几次呢？)，然后再次点开 WorkBuddy，准备把之前没做完的部分做完，结果发了指令，WorkBuddy 折腾了好几分钟愣是一直在思考，但就是一个字都不往外蹦，重试了好几次都是一样，只思考不输出任何内容；心想这下可能真完了，系统一定出问题了，赶紧备份；打开计算机，点开项目所在的 NTFS 分区，点了几次都没反应才发现，原来这个分区已经不可读了。

我要自己修吗？嗯，也不是不行，但既然现在用的是 deepin，这种麻烦的事当然是交给了小U同学，在免费版小U同学帮助下，大概梳理出了这次事故的时间线如下：

还贴心的分析出来问题原因是持续高压 I/O：WorkBuddy 直接在 NTFS 分区上读写项目文件，同时 deepin-anything 正在全盘索引扫描这 316G 的 NTFS 卷。对 Lexar NM620 这类入门级 NVMe 来说，这种持续高负载 + NTFS 驱动（ntfs3）并发访问，容易触发控制器挂起或驱动层 bug，最终表现为系统冻结。

你想问 deepin-anything 是啥？就是下图中文件管理器里面的索引功能哦。

分析完成后，小U同学还给出了恢复NTFS分区访问的解决方案

方案 A（推荐，最安全）：先以恢复模式只读挂载验证

sudo mount -t ntfs3 -o recover /dev/nvme0n1p5 /media/Another/Date

成功后 Date 分区即可访问。

方案 B：修复脏标志（更彻底，相当于让 Windows 下次开机自动 chkdsk）

sudo ntfsfix /dev/nvme0n1p5

ntfsfix 只清除脏标志、修复基础结构，不会删除你的数据。执行后再到文件管理器挂载 Date 即可。

我直接选择了方案B，完美解决了问题（附带一提，我也检查了检查 SSD 健康度，完美）。

所以，给各位还在使用NTFS分区存储数据的deepin用户提个醒，请尽量避免在 NTFS 分区中进行大量的读写操作（尤其是AI编程项目），可以的话，推荐将这些操作放到 Linux 分区来进行；毕竟现在的 deepin-anything 不太智能，它是真的会不分时间和场合的与其它程序争抢读写资源哦。

感谢小U同学的协助👍

后记：当然了，这个更大的原因应该是我的硬盘性能不够强大，驱动有Bug导致的。绝对不是想说小米的笔记本不好😂，尽管它卖个我的这台笔记本只提供了一年服务，只更新过一次UEFI，反馈多次的 UEFI 的 Bug 也石沉大海，但至少它现在还能用。