2015-12-22 63 views
0

我的问题可能是我对谷歌存储全球一致性的误解的结果,但由于我直到最近(11月中旬)才有过这个问题,现在看起来很容易重现,所以我想要澄清一下。这个问题发生在使用bdutil运行在计算引擎上的一段spark代码中,但是我可以使用gsutil从命令行重现。GCS - 全球一致性与删除+重命名

我的代码正在删除目标路径,然后立即将源路径重命名为目标路径。由于目标路径不再存在,因此在全局一致性的情况下,由于目标路径不再存在,因此src将被重命名为目标,但src被嵌套在目标中,就好像目标仍然存在并且不一致。

Hadoop的代码来重现的样子:

fs.delete(new Path(dest), true) 
fs.rename(new Path(src), new Path(dest)) 

从命令行我可以重现:

gsutil -m rm -r gs://mybucket/dest 
gsutil -m cp -r gs://mybucket/src gs://mybucket/dest 

如果原因是因为列表操作是最终一致和文件系统实现用列出操作以确定目标是否仍然存在,然后我明白了,然后是否有推荐的解决方案来确保重命名之前目标不再存在?

感谢, 卢克

回答

1

阅读后写(包括删除)操作是十分一致的,因此,例如,如果你这样做:

gsutil -m rm -r gs://mybucket/dest 
# Command output shows it removed gs://mybucket/dest/file1 
gsutil cp gs://mybucket/dest/file1 my_local_dir/file1 

这总是失败。

然而,以确定是否一个“目录”的存在,gsutil会必须执行最终一致的上市运作,以找出是否在谷歌云存储的平面名称空间中的任何对象有与“目录”的名称的前缀。这可能会导致您描述的问题,并且我期望hadoop代码的行为相似。

对于此问题,没有一致的解决方法,因为无法以强烈一致的方式检查是否存在前缀。

+0

谢谢。我想我会重新设计数据流,因此我总是在名称中创建一个带有时间戳的新“目录”,而不是试图替换现有的“目录” – lukeforehand