群晖 File Station 中移动内含大量（其实感觉也不是很多）文件的文件夹时速度非常慢

[Exp]

公司部门购买了一台群晖 1821+ 当作数据服务器来用，目前塞了 6 块硬盘组了一个 Raid5 存储池。

最近对其中的数据进行整理时发现，移动文件夹时速度巨慢无比，完全刷新了我对群晖 NAS 文件系统的认知。

一般来说，在同磁盘 /存储池中移动文件 /文件夹只是在记录中改变指针地址，理论上来说应该瞬间完成。但是群晖的表现实在是令人费解：速度奇慢，且任务进度条卡在 0%处不再改变，再过~1 小时 /若干小时之后再看，任务完成了。

咨询了产品售后，其也不清楚，在与官方技术沟通后告诉我说：群晖的 NAS ，在 File Station 中移动文件时需要重新做索引，速度就是很慢，类似于实际对数据进行了移动；如果想快速移动需要 ssh 登录进 NAS 系统后通过命令操作。

到目前为止，还是很难相信群晖 NAS 系统是这样的操作逻辑。对于企业用户来说，系统中包含数量庞大的数据是很正常的情况，如果对数据整理时采用这种逻辑，大大影响了正常的操作体验。

发现这个现象后开始在网上搜索，并没有发现有人提出类似的问题。不知各位朋友在使用群晖 NAS 时有没有遇到过这种情况？有没有什么更好的解决方案呢？

[itskingname]

我的是群晖 220+，通过 DS File 单独移动大文件的时候，是秒移动。但是如果一个文件夹里面包含大量小文件，那么速度确实非常慢。

[Huelse]

如果你有万兆网卡的话可以考虑本机打压缩包后再迁移，没有的话就 NAS 里压缩并迁移

[Exp]

@itskingname #1 可能跟大小没关系，单纯的是文件数量多。但是按道理也不应该这样操作才是，通常文件系统只移动顶层文件夹路径指针就好啊。

[Exp]

@Huelse #2 我本身数据移动就是在同一个 NAS 中移动，跟网卡会有关系的吗？

还有就是数据量本身数量和总量也很大（若干 T ，几十万 /上百万文件个数的级别），打包压缩可能也不现实。

[H97794]

试试
文件服务 高级设置 启用文件快速克隆

[ruanimal]

把文件索引关了可能就快了

[Exp]

@H97794 #5 系统版本是 7.1.1 update3 ，请问从哪儿进 [文件服务] 呢？

[Exp]

@ruanimal #6 客服说文件索引是 File Station 默认开启的，无法关闭。不知是不是指的这个：



前期数据文件夹一直在建立 Universal Search 文件索引，这个位置也没有办法更新。目前看创建文件索引的任务结束了，这里发现出现移动慢问题的数据文件夹已经不在这里了。

中间只进行了对其在 Syology Drive 管理控制台中进行了停用版本控制的操作。根据客服说法，Syology Drive 与 Universal Search 文件索引 是两回事，一个是应用层面问题，一个是系统层面问题。我取消 Syology Drive 中的版本控制应该不会导致 Universal Search 中的设置更改才对。

不知后续再操作会不会还是同样的问题。

[lookStupiToForce]

你不妨监测一下群晖在你说的这种移动大量文件却相当慢的情形时，其硬盘 IO 状况（注意是 IO 数量不是硬盘速率）
如果 IO 量简单换算后（ IO 数除一下文件总数）相比移动单个小文件时比较大，有理由怀疑群晖在此过程中真的对文件进行了“碎片整理”

类似于 windows 的磁盘碎片整理，数据库的收缩 /真空功能，能理解吧？

另外就算没有碎片整理，非连续存储空间的零散文件的 IO 本身也挺费时的，你说的情形同样适用于删除文件（也是改个标记的事），这种情况你可以 [镜像硬盘] （理论上镜像硬盘可以完整复刻文件碎片化情况）后再做个删除测试

[Exp]

@lookStupiToForce #9 感谢提供思路，当时在移动文件过程中只看了一眼磁盘读写性能，当时的速度只在~1MB/s 左右。（下午位置和选项）没有看 IO 状态（ IOPS ？）



最后说的碎片整理和非连续存储空间的零散文件的 IO 问题。因为我们这台机器是新组装的，在空磁盘空间状态下首次填入的数据，还没有经过大家使用，所以我个人感觉应该也不存在零散碎片文件的问题。

问题已经提了工单，看后续群晖技术支持的回复了。

再次感谢！

[lookStupiToForce]

@Exp #10 IO 状态得 SSH 进去用命令看，iostat 、sar 之类的
不过如果你确定当时只有 1MB/s 左右，那这个速率可以肯定是包含大量随机访问了。

我详细回看了一下以前的文章收藏，感觉可能是你的使用情景触碰到了文件系统的瓶颈（也不知道你用的啥文件系统，截图里没看到。ext4 ？ btrfs ？），贴一下看对你有没有帮助吧：

www[.]zhihu[.]com/question/22555963/answer/1671045642
"""
单个 1G 的文件，在现代文件系统里，可能至多需要十次不到的寻道就能全部读取；而 1024 个 1M 的细小文件呢，那就相当于 FAT 时代、存在一千个文件碎片的单个大文件——起码多了一千次寻道呢，怎么可能不慢。

事实上，这样算还是算少了。因为磁盘驱动必须先读取文件分配表，然后才能拿到“指针”、才能去按照“指针”指示寻找对应的扇区；那么对 1G 的大文件，文件分配表寻道一次，扇区寻道一次，差不多就够了；而对 1M 的一堆小文件呢，文件分配表寻道 1024 次，每个文件的首扇区又要寻道 1024 ，实际多了两千多次寻道。

按每次寻道需要 15ms 算，额外就需要 15X2000=30000 毫秒，也就是 30 秒时间；而现在的硬盘在顺序读写时平均读写速率可以飙到 170M/s 以上；哪怕按 100M/s 算，1G 的文件 10 秒也能传完了；结果寻道愣是多寻了 30 秒——慢了足足 3 倍！

而且，这里仅仅算了读取；写入时，小文件也需要先写文件分配表后写内容，这显然又是一堆寻道……不过这个场景过于复杂（比如同个磁盘不同分区拷贝、不同磁盘之间拷贝等等，细节各有不同），就不深入分析了。
"""


如果要我来猜的话，就是系统批量写入的时候，是一个顺序，记作 A ，读取的时候，操作系统提交给文件系统的是另外一个顺序，记作 B ，B 相较 A 已经不同了，而文件系统将 B 优化后的读取顺序，记作 C 。C 虽然已经按照磁盘文件实际位置做了大量优化，但其相对于 A ，还是有大量乱序，导致了随机 IO 占比过高

[Exp]

@lookStupiToForce #11



文件系统是 Brtfs 。

您的猜测可能是对的，这个 NAS 我之前听部门同事说，其中 NAS 中的数据是通过数据恢复得来的。可能在恢复过程中的写入本身就不是顺序的。后期我再问问数据是怎么存入的。

[ltkun]

群晖会在每个目录下生成一个索引文件的隐藏目录 对备份啥的没啥用 除了慢