我在Google Cloud中有一个bucket文件夹，里面有大约47GB的数据。我启动了一个新的KubernetesStatefulSet(在我的Google Cloud Kubernete集群中(。StatefulSet中的容器所做的第一件事是使用gsutil -m rsync -r gs://<BUCKET_PATH> <LOCAL_MOUNT_PATH>将bucket文件夹内容同步到本地安装的文件夹，该文件夹对应于Kubernetes Persistent Volume。此StatefulSet的持久卷声明请求125Gi的存储，并且仅用于此rsync。但gsutil同步最终碰壁，pod的磁盘空间(持久卷中的空间(用完，gsutil抛出一个错误：[Errno 28] No space left on device。这很奇怪，因为我只需要从bucket中复制47GB的数据，但Persistent Volume应该有125Gi的可用存储空间。
我可以通过使用kubectl get pvc和kubectl get pv确认已为永久卷声明和永久卷提供了适当的大小。如果我在pod中运行df -h(kubectl exec -it <POD_NAME> -- df -h(，我可以看到挂载的路径存在，并且它具有预期的大小(125Gi(。在同步期间使用df -h，我可以看到，当它最终达到No space left on device时，它确实占用了持久卷中的所有可用空间。
此外，如果我提供200Gi的持久卷并重试同步，则它成功完成，并且df -h显示持久卷中使用的空间是47GB，正如预期的那样(这是在gsutil rsync完成之后(。
因此，gsutil rsync在同步时使用的空间似乎比我预期的要大得多。为什么会这样？有没有办法改变gsutil rsync的工作方式，使其不需要比必要的更大的持久卷？
需要注意的是，有很多单独的文件，在同步期间，pod会重新启动大约8次。
rsync将首先将内容传输到目标文件夹中的临时文件。如果成功，它将重命名该文件，使其成为目标文件。如果传输失败，临时文件将被删除。根据链接，您可以尝试在命令中添加--inplace标志："此选项更改rsync在需要更新文件数据时传输文件的方式：rsync不是默认的创建文件的新副本并在完成后将其移动到位的方法，而是将更新后的数据直接写入目标文件。">