@totoro625 因为 V2EX 不让分享破解软件。实际上这个破解版网上很好找哦

@francis59 我现在每天扫一遍，可以看出来每天都有新的区块错误。
（目前这块盘还在等待上门换新）

@fuxkcsdn
你这个型号在网上能找到 0e 案例。
《作为三星 pm9a1 固态 0e 报错 /数据损坏的早期、二度受害者，谈谈科学的预判和检测方法》
https://www.v2ex.com/t/879433#reply7
建议你按照我这篇里面的检测方法每周做一次读取扫描吧。
视频的话除非你用于实时编辑，如果静态保存还是尽快转移为好。
虚拟机的话整体备份出去。我这边实测虚拟机受到数据损坏影响后，虽然还能开机，但是虚拟磁盘性能有很诡异的异常，经常 100%占用（宿主机实际占用很低）

@nkcfc 核心问题在于报 0e 的对应的究竟是什么文件发生损坏。你可以用 Hard Disk Sentinel 等类似软件做个全盘读取测试，最好挑这种可以判断出损坏的数据块对应的文件路径；或者直接人工测试，挑几个大型游戏或者大文件尝试复制到别的盘，如果出现数据损坏，会报读取源文件错误。

根据我个人使用场景和实际翻车体验看，虚拟机的虚拟磁盘文件、大文件视频、分片的游戏数据文件是最容易在 0e 有计数的情况下翻车的

你当然有“把这次三星固态问题想得不那么严重”的自由，但你提供的论据是站不住脚的，而且试图引导的方向不道德也不负责任。

一旦大范围出现这种 ssd 数据损失的情况，对于涉及的厂商和问题型号，必然要怀着最最悲观和最最警惕的态度，宁可矫枉过正。

难道你以为大家买旗舰固态都是装游戏打游戏，数据丢了重新下也无妨吗。多少人在上面运行重要的生产力环境，多少创意工作者临时存放着极端重要的原始文件。这些东西没了的风险和代价是能承受的吗？

我这边联想品牌游戏主机，出厂三星 pm9a1 2T ，今年 3 月已经因为 0e 记录猛涨+数据损坏换新一次了，换新后用到这个月又出一模一样的问题了。

一模一样的问题在我身上连续出现两次，不可能是小概率随机事件。

当然你可以说联想的备货或者给我换的新件是同批次生产的，但对于这个问题批次，出问题的概率不就是 100%了吗。。何来题主脑补的“小概率”或百分之个位数？而且还有这么多工艺缺陷的说法，就不太可能是某一批次凑巧的品控问题了吧。

题主一个很大的问题是，你的测试方法是短时间内猛做读写操作，这种方法完全无法恰当模拟正常的使用情况。根据我个人的经验，出 0e 问题需要较长的运行时长，我都是 24 小时不关机，通电三四千小时会遇到。此时写入量才 50-60TB ，健康度在 96%，就已经出现了不可挽回的超大文件数据损坏，而且这种损坏没有前兆。在触发某个倒霉文件前，日志不会有任何报错。直到发现问题，摆在面前的已经是恐怖的循环冗余检查了。

在很多特定使用条件中，读写操作可能不多，但由于 cpu 或 gpu 高负载，可能同时影响 ssd 散热，导致长期频繁运行在较为临界的工作温度下，这些都可能成为问题诱因。。。

外网可以直接 smb 协议挂载吗？

没实测过，但目前国内几乎所有主流网盘服务商都在搞哈希值侵权数据库，配合版权投诉后的批量删除。目前网盘服务商著作权侵权诉讼中，哈希值算法已经被原告、公正机构、律所、知识产权维权公司玩得炉火纯青了。比较嚣张的阿里云现在也已经被各大影视平台维权机构注意到。

更何况现代版权法律体系本来就是传承自国外，很难相信谷歌存储供应商没有类似风控机制。

除非压缩加密或者分卷。直接传源文件，不值得这样冒险，你自己也感觉不到安心啊。

问题本身已经很偏门了，问得那么笼统无从下手啊。
你自己完全可以先做几轮测试：
1 、wifi 不行，有线连接呢？ pc 端不行，手机端呢？外网上传不行，局域网上传呢？
2 、猜测是上行带宽限制？可以做一下内网和外网测速，iperf3 测试呀
3 、打开了 Turbo ACC ？有没有尝试过关闭。一般排查软路由问题的思路是剔除掉除基本联网功能以外的所有附加功能，包括代理 去广告 dns 软件分载 硬件加速 ipv6……测试没问题了再一个个打开，排除法嘛。
3 、试着换固件？红米定制 op 固件应该有硬件加速方案，你去细品恩山近年来固件大佬的更新日志，什么内存泄露，驱动问题，反复重启……从大体上看就不是太稳定的平台，应该及时考虑换个固件再做测试呀。我这边连最最通用的 x86 方案，能做到完全没问题正常使用的第三方固件都寥寥无几，不要吊死在一棵树上
4 、进一步排查？除了提供表象问题，为了方便网友帮忙，应该做一些力所能及的其他工作：提供正在使用的软路由插件 提供 op 系统日志和内核日志 提供上传客户端的 wireshark 抓包日志……各种蛛丝马迹都放上来比较容易定位问题

@ragnaroks 好嘞感谢！我再试试

根据我的经验，首次报 0e ，一般在正常使用 ssd 半年左右。
而且光被动看 S.M.A.R.T 没有用，必须在特定情况下恰好命中了某个损坏的文件，或者做一次全盘扫码 /chkdsk ，报错以后，0e 和日志错误数才会涨。

@cubecube @chackchackGO @iloveayu @ysc3839
我刚刚做了几轮测试，我收回上面说的话哈哈哈。无论是虚拟化 windows 系统还是 linux ，总线程一致的情况下在 vmware 上设置各种处理器数和核心数的搭配组合，经过比较简单的测试发现性能差别微乎其微。这里奉上测试记录：

宿主机 CPU：9-12900K win11 22000.918
VMware 版本号：vmware 16 pro 16.2.3 build-19376536
虚拟机测试镜像：ubuntu-22.04-live-server-amd64.iso （ ubuntu 官方镜像），安装时不选择 minimized 选项
虚拟机设置：
由于宿主机开启了 Hyper-v ，所以 vmware 虚拟机设置里“虚拟化引擎”三个勾全去掉。
移除声卡 /打印机 /USB 控制器，禁用内存页面休整，为启用了 Hyper-V 的主机禁用侧通道缓解，BIOS 引导

测试工具：使用 Lemonbench 标准模式 CPU Performance Test （ Standard Mode ，3-pass @ 30sec ）

[ubuntu 虚拟机+宿主机 vmware 进程强制只调用 8 大核 16 线程]
2CPU 8core
单核 4317
多核 35842

8CPU 2core
单核 4312
多核 35869


[ubuntu 虚拟机+宿主机 vmware 进程不设置 CPU 相关性，调用 8 大核 8 小核 24 线程]
1CPU 24core
单核 4326
多核 58438

24CPU 1core
单核 4345
多核 58329

8CPU 3core
单核 4334
多核 58985


Windows 跑 CPU-Z
[Windows 10 1CPU 16core 宿主机分别调用 8 大核 16 线程 /8 大核 8 小核 24 线程]
单核：756.1 751.8
多核：7583.8 8493.9

[Windows 10 2CPU 8core 宿主机分别调用 8 大核 16 线程 /8 大核 8 小核 24 线程]
单核 752.8 755.9
多核 7577.2 8444.4


附言：
虽然看上去在大小核架构的宿主机 CPU 上，不屏蔽小核，性能测试结果似乎不会有影响，也没有出现“小核拉满，大核围观”的情况。但在实际跑应用的时候，或多或少调用会出问题。

@ragnaroks 之前也是直接改虚拟机配置文件的，后来发现有时候不太稳定？比如有时生效，有时不生效。单纯用 windows 自带任务管理器，宿主机或者虚拟机重启后相关性设置就恢复默认值了。最后还是发现 prosess lasso 可以长期保持相关性设置的稳定。另外要吐槽的是，无论用什么方法设置 VMware 虚拟机的 CPU 相关性来屏蔽小核，虚拟机开机的时候极大概率会报错：未能开启“X:\^\^.vmx"。疯狂点开机可以跳过这个错误。