ind*_*two 6 file-transfer command-line windows-10
我有 16 个子目录,每个子目录包含 1m-1.5m 个文件(总共大约 1800 万个文件),但我需要所有文件都位于一个目录中。每个文件都很小(每个文件 35-100 字节)。这些文件的总大小相对较小(大约 600mb),但似乎是文件数量太大导致了问题。
到目前为止我已经尝试过:
Windows move:甚至还没有开始。它表示需要“大约一天”的时间来计算此举。2个小时后放弃了calculating。
DOSmove:这对于前 500-600k 个文件(每秒移动大约 10k 个文件)效果很好,但当它拖向百万个大关时,速度开始明显减慢,每 2 秒大约移动 100 个文件。
7Zip:我读过一些建议,认为压缩整个文件夹然后将其提取到目标位置会更快;然而,使用 GUI 几分钟后资源管理器就崩溃了;使用命令行非常慢(每隔几秒 100 个文件)
DOS robocopy:昨天已经移动了大约 1m 个文件,我robocopy src_folder dest_folder *.log只是为了移动第一个目录中的最后一个文件。移动约 12k 个文件花了 27 分钟。
无论我选择哪种方法,目标文件夹中的文件数量似乎都是导致问题的原因。如果目标中的文件超过一百万个,则无论采用何种方法,移动/复制都会减慢速度。
关于如何实现这一目标的任何想法不需要几天/几周的时间?作为参考,它位于单台机器上的单个 SSD 上:64 位、16GB RAM、8 个线程。
使用DSynchronise,因为它是免费的!它之所以对您来说是一个不错的选择,是因为它不像 Windows 资源管理器那样在复制之前计算队列中每个文件的数量和大小。它只是立即复制。
但是,您可以勾选该复选框,以便它首先计算磁盘空间。您还可以选择存储提前删除或覆盖的每个文件的备份。您可以使用预览模式,以便在实际执行同步之前测试同步将如何发生。
另请记住,它并不总是按字母数字顺序复制文件,因此,如果复制或同步突然停止,对您造成损害,那么您可能必须从头开始。
我发现旧版本 2.30.1 比新版本(当时是 2.41.1)更容易使用且速度更快。


| 归档时间: |
|
| 查看次数: |
9901 次 |
| 最近记录: |