一位长期写技术博客的老手,把用了多年的Synology NAS往UniFi UNAS Pro 8上搬数据,原本以为是个无聊的体力活——都支持SMB,网络也是10GbE,Robocopy这种工具用了几十年。结果拷到92%,Windows甩出一个错误665:“the requested operation could not be completed due to a file system limitation”。
排查下来,元凶是一首m4a音乐文件里藏的NTFS备用数据流(Alternate Data Stream),一张封面jpg被塞进了文件系统层的隐藏流,Robocopy处理到那里就卡死。加上/COPY:DATX跳过ADS,文件顺利过去。这只是故事的开头。
92%报错之后,更麻烦的是忽快忽慢
跳过ADS之后,大批量迁移开始了,速度却像坐过山车:一会儿几百Mbps,一会儿几乎停住。他怀疑过磁盘、怀疑过老NAS撑不住,最后排查出问题出在/Z参数——这个用来支持断点续传的开关,微软官方文档早就提醒过,它引入的checkpoint记录机制会明显拖慢速度。去掉/Z,换成/MT:4控制并发,速度回升到每秒约187MB。
这一步验证了一件常被忽略的事:命令行开关描述的是行为,不是性能承诺。/Z换稳定性,/MT换并发,/J换I/O模型,三者谁快谁慢,完全取决于两端的网络和存储配置,不存在一套万能参数。
真正有意思的地方是,即便调对了参数,吞吐依然不稳定。答案不在Robocopy,在协议层。
SMB Multichannel:旧NAS有,新NAS没写
老款Synology虽然只有四个1GbE口,但SMB3支持Multichannel——同一个客户端会话可以同时占用多条网络路径叠加带宽,这和常见的链路聚合(LACP)是两回事:链路聚合服务的是多客户端分流,Multichannel服务的是单一会话提速。Synology官方文档对这两者做了明确区分。
UNAS Pro 8的硬件参数看起来占优:8盘位,三个10GbE口(两个SFP+加一个RJ45),16GB内存。但Ubiquiti官方规格页和社区反馈都指向同一个事实——UNAS Pro 8目前没有文档化支持SMB Multichannel。旧NAS靠协议特性把四条1GbE路径拼成接近4Gb/s的实际带宽,新NAS的三个万兆口却可能各自为战,单一会话吃不满硬件规格。
三个万兆口是硬件规格,不是吞吐承诺
这也解释了为什么调完所有Robocopy参数,速度依然时快时慢——协议层没补齐,应用层再怎么调参数,天花板还是那道天花板。
社区聚合的实测数据把这道落差摆得更直白:官方基准约637MB/s,社区实测低点约300MB/s、多数落在300-520MB/s区间,而同场景对照下的Synology能跑到约950MB/s。这不是某个用户网络没配好,是一群人反复撞到同一个天花板。
- 风险.三个10GbE≠30Gb/s聚合带宽,单会话受限于协议支持,买硬件规格前先确认协议清单
错误665不是ADS专属病
顺手纠正一个容易被这次经历带偏的印象。微软官方文档把错误665定义为NTFS元数据耗尽——ATTRIBUTE_LIST_ENTRY用尽,常见根因是文件严重碎片化,ADS流本身并不是官方文档列出的典型诱因。这次报错碰巧撞上ADS,是因为封面图流本身也占用了一条额外的属性记录,凑巧触发了同一机制。
这句话拆开讲就是:跳过ADS这次管用,不代表下次665报错也该往ADS上找。碎片化的老硬盘、复杂的属性列表,都可能触发同一个错误码。把个案经验当成万能解药,是跨设备迁移里最容易踩的坑。
搬家这件事,搬到最后往往才发现丢了什么。Ubiquiti近两年从网络设备切入NAS市场,UNAS Pro 8对标的是Synology、QNAP这类老牌厂商,但第三方评测普遍认为它更像一台“简单快速的UniFi集成存储”,而不是完整替代品——iSCSI缺失,AD/LDAP集成较弱,应用生态也远不及老牌NAS。
- 结论.从Synology搬到UniFi生态,搬走的是文件,搬不走的是协议成熟度和十几年攒下的功能面