请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
群晖 File Station 中移动内含大量（其实感觉也不是很多）文件的文件夹时速度非常慢
Exp · 2023-02-14 10:24:34 +08:00 · 2746 次点击这是一个创建于 633 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司部门购买了一台群晖 1821+ 当作数据服务器来用，目前塞了 6 块硬盘组了一个 Raid5 存储池。
最近对其中的数据进行整理时发现，移动文件夹时速度巨慢无比，完全刷新了我对群晖 NAS 文件系统的认知。
一般来说，在同磁盘 /存储池中移动文件 /文件夹只是在记录中改变指针地址，理论上来说应该瞬间完成。但是群晖的表现实在是令人费解：速度奇慢，且任务进度条卡在 0%处不再改变，再过~1 小时 /若干小时之后再看，任务完成了。
咨询了产品售后，其也不清楚，在与官方技术沟通后告诉我说：群晖的 NAS ，在 File Station 中移动文件时需要重新做索引，速度就是很慢，类似于实际对数据进行了移动；如果想快速移动需要 ssh 登录进 NAS 系统后通过命令操作。
到目前为止，还是很难相信群晖 NAS 系统是这样的操作逻辑。对于企业用户来说，系统中包含数量庞大的数据是很正常的情况，如果对数据整理时采用这种逻辑，大大影响了正常的操作体验。
发现这个现象后开始在网上搜索，并没有发现有人提出类似的问题。不知各位朋友在使用群晖 NAS 时有没有遇到过这种情况？有没有什么更好的解决方案呢？
 |
1
itskingname 2023-02-14 10:47:05 +08:00
我的是群晖 220+，通过 DS File 单独移动大文件的时候，是秒移动。但是如果一个文件夹里面包含大量小文件，那么速度确实非常慢。
|
 |
2
Huelse 2023-02-14 10:50:42 +08:00
如果你有万兆网卡的话可以考虑本机打压缩包后再迁移，没有的话就 NAS 里压缩并迁移
|
 |
3
Exp OP @itskingname #1 可能跟大小没关系，单纯的是文件数量多。但是按道理也不应该这样操作才是，通常文件系统只移动顶层文件夹路径指针就好啊。
|
|
4
Exp OP |
 |
5
H97794 2023-02-14 11:41:47 +08:00
试试
文件服务 高级设置 启用文件快速克隆 |
 |
6
ruanimal 2023-02-14 11:50:38 +08:00
把文件索引关了可能就快了
|
|
8
Exp OP @ruanimal #6 客服说文件索引是 File Station 默认开启的，无法关闭。不知是不是指的这个：
 前期数据文件夹一直在建立 Universal Search 文件索引，这个位置也没有办法更新。目前看创建文件索引的任务结束了，这里发现出现移动慢问题的数据文件夹已经不在这里了。 中间只进行了对其在 Syology Drive 管理控制台中进行了停用版本控制的操作。根据客服说法，Syology Drive 与 Universal Search 文件索引 是两回事，一个是应用层面问题，一个是系统层面问题。我取消 Syology Drive 中的版本控制应该不会导致 Universal Search 中的设置更改才对。 不知后续再操作会不会还是同样的问题。 |
 |
9
lookStupiToForce 2023-02-14 14:09:58 +08:00  1
你不妨监测一下群晖在你说的这种移动大量文件却相当慢的情形时，其硬盘 IO 状况（注意是 IO 数量不是硬盘速率）
如果 IO 量简单换算后（ IO 数除一下文件总数）相比移动单个小文件时比较大，有理由怀疑群晖在此过程中真的对文件进行了“碎片整理” 类似于 windows 的磁盘碎片整理，数据库的收缩 /真空功能，能理解吧？ 另外就算没有碎片整理，非连续存储空间的零散文件的 IO 本身也挺费时的，你说的情形同样适用于删除文件（也是改个标记的事），这种情况你可以 [镜像硬盘] （理论上镜像硬盘可以完整复刻文件碎片化情况）后再做个删除测试 |
|
10
Exp OP @lookStupiToForce #9 感谢提供思路，当时在移动文件过程中只看了一眼磁盘读写性能，当时的速度只在~1MB/s 左右。（下午位置和选项）没有看 IO 状态（ IOPS ？）
 最后说的碎片整理和非连续存储空间的零散文件的 IO 问题。因为我们这台机器是新组装的，在空磁盘空间状态下首次填入的数据，还没有经过大家使用，所以我个人感觉应该也不存在零散碎片文件的问题。 问题已经提了工单，看后续群晖技术支持的回复了。 再次感谢！ |
|
11
lookStupiToForce 2023-02-14 17:10:59 +08:00
@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 占比过高 |
|
12
Exp OP @lookStupiToForce #11
 文件系统是 Brtfs 。 您的猜测可能是对的，这个 NAS 我之前听部门同事说，其中 NAS 中的数据是通过数据恢复得来的。可能在恢复过程中的写入本身就不是顺序的。后期我再问问数据是怎么存入的。 |
 |
13
ltkun 2023-02-14 22:26:07 +08:00
群晖会在每个目录下生成一个索引文件的隐藏目录 对备份啥的没啥用 除了慢
|
Select Language