rsync同步本地挂载的VM共享目录时速度骤降的原因及优化方案咨询
rsync同步本地挂载的VM共享目录时速度骤降的原因及优化方案咨询
看起来你遇到的问题核心是SMB协议与rsync的元数据密集型操作不兼容,再加上VM虚拟化层的额外开销,导致速度雪崩式下降。我来帮你拆解原因,再给几个针对性的优化方案:
一、为什么rsync会比cp/拖放慢这么多?
- SMB的元数据处理瓶颈:Mac的SMB共享虽然是本地VM的,但本质还是走网络协议栈。rsync默认会对每个文件做大量元数据检查(比如修改时间、大小、权限、所有者等)——这是它增量同步的核心,但SMB对频繁的小批量元数据请求(比如
stat操作)响应效率极低,远不如本地文件系统。而cp或者Finder拖放更偏向于批量数据传输,对元数据的检查/同步逻辑更简单,所以受SMB的影响小很多。 - rsync的网络适配逻辑:当rsync检测到源是网络挂载点时,会默认启用一些针对远程传输的逻辑(比如更严格的校验、加密兼容等),这些在本地VM场景下完全是冗余开销,反而拖慢了速度。
二、已尝试的SSH方案优化:从40分钟逼近原20分钟
你已经切换到SSH方式(user@host:/path/to/data),这步很关键,因为SSH的文件传输效率比SMB高很多。要进一步提速,可以调整这些参数:
- 禁用不必要的加密开销:本地VM传输不需要高强度加密,用轻量加密算法减少CPU消耗:
rsync -ahPmW --verbose --delete --no-compress -e "ssh -o Ciphers=chacha20-poly1305@openssh.com" /my/local/directory /my/external/drive/ - 复用SSH连接:避免每次传输小文件都重新建立SSH连接,减少握手开销:
rsync -ahPmW --verbose --delete --no-compress -e "ssh -o ControlMaster=auto -o ControlPath=/tmp/ssh-%r@%h:%p -o ControlPersist=60s" /my/local/directory /my/external/drive/ - 跳过冗余的元数据同步:如果不需要严格同步权限/所有者(毕竟都是Mac系统),可以加上
--no-perms --no-owner --no-group,减少元数据操作:rsync -rPmW --verbose --delete --no-compress --no-perms --no-owner --no-group -e "ssh -o ControlMaster=auto -o ControlPath=/tmp/ssh-%r@%h:%p -o ControlPersist=60s" /my/local/directory /my/external/drive/
三、针对SMB挂载场景的应急优化(如果不想切换到SSH)
如果你暂时需要保留SMB挂载的方式,可以通过调整rsync参数大幅减少元数据开销:
- 用文件大小判断同步需求:跳过修改时间检查,仅通过文件大小判断是否需要同步(适合文件修改后大小大概率变化的场景):
rsync -ahPmW --verbose --delete --size-only /my/local/directory /my/external/drive/ - 强制全文件传输+跳过权限同步:保留
-W(全文件传输,避免rsync增量校验的开销),同时去掉不必要的属性同步:rsync -rPmW --verbose --delete --size-only --no-perms --no-owner --no-group /my/local/directory /my/external/drive/
四、终极提速方案:绕过网络协议层
如果想彻底回到原来的15-20分钟速度,最好的办法是绕过SMB/SSH这些网络协议:
- 直接在VM内运行rsync:把外部Thunderbolt 3 SSD挂载到VM内部(VirtualBuddy应该支持直接挂载USB/Thunderbolt设备),然后在VM里执行你原来的rsync命令,完全走本地文件系统,性能和之前一致。
- 使用VM原生共享文件夹:VirtualBuddy基于Apple的虚拟化框架,应该支持原生的文件夹共享(而非SMB),这种共享是直接的文件系统映射,没有网络协议的开销,性能远优于SMB。
最后,你提到的“rsync是否自动开启了额外的加密/压缩”——确实,当源是网络挂载时,rsync默认可能会启用一些适配逻辑,但通过--no-compress可以明确禁用压缩,而加密是SMB/SSH带来的,不是rsync本身的。
备注:内容来源于stack exchange,提问作者Jeremy W




