我们一直在使用gsutil来保持开发和部署框与GCS存储桶同步近2年，没有任何问题。桶中有大约85k个物体。
直到最近，这完美运行：我们运行部署框 - ＆gt; GCS rsync大约每15分钟左右，以备份所有新上传的资源，然后是GCS - ＆gt;每当我们想刷新本地开发数据（在OSX El Capitan上运行）时，开发框rsync。
在过去的几个月里，GCS-＆gt; dev rsync开始膨胀，下载的图像越来越多。
最初我只是想到了＃34;太棒了，我们上传了更多的资源＆＃34;，但它的增长速度比数据快，直到今天它似乎正在下载整个85k图像。
我已经在正确的位置仔细检查了我，命令是否正确，路径是否正确等等。对于所有find . -type f | wc -l输出正在滚动的令状和令人满意的＆＃34;复制......＆＃34;和＆＃34;正在下载......＆＃34;消息，好好并行使用我们的100mbps连接，当我去另一个终端并每隔10秒在目标目录上运行gsutil时，它显示每分钟只添加2或3个新文件。我看一下gsutil说它现在正在下载的文件的修改时间，并且在绝大多数情况下，他们已经过了很长时间，在一年或更长时间内没有变化。含义：它使用大量的时间和带宽下载所有数据，所有这些都是为了几百个文件。
最近的OSX gsutil-discuss版本有变化吗？可能有错误吗？我怎么会开始跟踪这个呢？还是报道呢？新闻组gs-discussion和gce-discussion已归档，gsutil中的谈话完全是关于使用GCE实例中的{{1}}。
谢谢！
答案 0 :(得分：4)
我有一个类似的问题，一遍又一遍地同步相同的文件。我没有那么多文件，因此您可能需要检查性能但我决定使用-c选项强制使用校验和而不是在构建过程中本地修改的mtime。
我认为（并希望）文档略有错误，说明
如果源和目标的大小为，则比较文件的校验和 以及mtime匹配
因为它似乎使用校验和，即使mtime不匹配
答案 1 :(得分：1)
gsutil 4.20（2016-07-20发布）修改了rs change detection algorithm。现在，它不仅仅比较本地文件的大小和云对应文件的大小，而是比较本地文件的大小和文件修改时间。使用rsync上载文件时，文件修改时间存储在文件的自定义用户元数据中。如果不存在，则使用对象创建时间。