Google File Stream 非常可怕的 Bug，随机添加已存在的数据到另一个文件，大家小心

Google File Stream 老用户了，最近更新了 30.1 版本以后突然经常出现 PDF/AI 文件编辑过以后随机打不开的情况，像这样：

直到有一天客户和我说，我们发过去的 PDF 文件是损坏的，但是通过某些 PDF 阅读器能看得到一张别人的合同的一部分，这可真的把我们吓得不轻，赶紧抽样了那些损坏的 PDF 文件做了比对，发现：

这些 PDF 文件损坏的原因是一样的，是这个文件随机包含了一部分额外的数据，因此尺寸、文件大小都增加了很多。

于是我们提取了这部分数据，发现居然是一个多媒体文件，而这个文件正是另一个 Google File Stream 里已经存在的 PDF 当中的一张图。也就是说，GFS 被更新版本以后的这个 bug 会随机的把已经存在你 GFS 里面的文件的一部分随机的插入到你最近更改的文件当中去，这个随机部分可以是你硬盘里的小姐姐，也可以是机密合同。细思极恐。

联系了 G Suite Business 的技术支持，只说有可能是服务器问题，没有任何实质性帮助，连滚回的安装包居然都提供不出来。

各位 G Suite 的 Google File Stream 用户发邮件之前一定记得查验一下自己发的文件，这种诡异的 Bug 实在是坑爹啊！！！

8e47e42

2019-04-02 10:29:57 +08:00

@PP 有疑新算法下 cache 配置出现问题，毕竟 gfs 的 cache 问题也不是一天两天了

x7395759

2019-04-02 10:40:15 +08:00

收钱的吗？

8e47e42

2019-04-02 13:24:52 +08:00

@x7395759 必须的，G Suite Business，不然哪里会有人理你

说来好笑我们前段时间居然还想升级到 G Enterprise，还好没有升

janssenkm

2019-04-02 13:43:41 +08:00

谷歌大叔的 drive 应该类似 ClusterFS, Ceph,HDFS 等，将文件拆成一个个数据块后以分布式方式存储。在某处维护一套索引机制，一个文件有一个唯一标识码，通过标识码和数据包顺序标识引用来实现文件的读写操作。
楼主遇到的问题我猜测是因为这几个原因导致吧，
1. 文件标识码计算方式遇到冲突，也就是出现两个或三个文件计算标识码的算法出现了雷同，这样就会出现文件不一致的情况。
2. 一个文件拆分多个数据包后会将多个数据包分别存放在不同服务器上，刚好某个数据包解析存储的服务器包括冗余服务器接收到该数据包时出现标识码丢失部分内容，过程也许很复杂，但确确实实丢了一位。比如原文件标识码为 1173734, 可丢失一位后变成 117373，两个不同标识码就代表了不同文件，所以就出现某个文件丢失了一个数据块，而另一个文件多了一个数据块。

数据量小时这些问题很难复现，在达到谷歌这种巨巨巨巨巨量数据块下，我觉得还真有可能，而导致故障的原因也许只是某个小小寄存器校验失败。对于巨量存储环境下，这种错误几乎可以忽略了。因为要他不报错还真不可能，只是这微乎其微的概率刚好被楼主遇到了。

给楼主一个建议，分布式存储原理下的数据存储都会有一定几率造成数据包异常，我们只能尽量减少发生概率。有条件的话，
1. 建议存放时做一下校验，本地生成一个 md5，存上去后再抓回来做一个校验，两个值相同时才能认为存入成功。
2. 检查调用的 api 是否使用了老接口，保证全部走 SSL，这个可以防止被污染和篡改。谷歌有些老接口不知还存在否，那可是货真价实的 http，虽然谷歌在努力走全 HTTPS，但也许会有漏网之鱼，刚好这一瞬间遭遇了污染劫持篡改也有可能。

dxppp

2019-04-02 13:52:29 +08:00

YouTube 也是在掉链子，谷歌💊
https://www.v2ex.com/t/551225

skyfree

2019-04-02 14:40:47 +08:00

还有这么大的 bug? 建议国内使用 G Suite 的公司可以看看我们开发的 G Suite 备份软件：CubeBackup https://www.cubebackup.com . 真的是个非常好用的企业数据备份工具

CrabAss

2019-04-02 15:16:14 +08:00

关注

8e47e42

2019-04-02 18:44:42 +08:00

@janssenkm
我们有帮 Google 做 log 分析（对大家没看错 9102 年谷人希现在都没有处理完这个 critical bug，甚至连 log 分析结果都没有给），基本应验你说的 2，Google Drive File Stream 的虚拟驱动有问题，导致 actually 和 expected 的不同，从而在写入的时候导致错误，具体体现为报错日志和出问题文件的写入时间高度一致，服务器上是不是有更进一步的问题尚不明确，但是 local 的 GFS 是真的有问题，建议大家别用了。

更可怕的是我们做 research 的时候发现了这个： https://www.greyhathacker.net/?p=1041
而这种级别的 bug，Google 根本就没有发任何通知。