关于Google Drive间数据转移的一个脑洞验证

云服务发展这么多年，服务器配置可以强到离谱。最近导数据，我发现瓶颈是硬盘。
Azure和aws的ssd，给的IOPS都挺拉胯的。Google我用自己申请的账号，iops能到12W，但是巨贵，一天能干3000多块港币。
这也可以理解，毕竟用再猛的固态，分配给多个用户，iops平均就低了。
网络很强，即使没多高配置的服务器，也能给个几G，但是ssd没法同时读写这么快，而且是多线程的同时读写。
然后高性能ssd只有Google有，但是贵到没法用。
然后我就想，能不能搞个大内存的机器，然后用内存直接虚拟盘，这样瓶颈就转移给网络了，这个瓶颈毕竟比ssd读写好多了。
理想的情况是，让Google Drive对拷形成一个完美的生产者-消费者模型。

结果把内存虚拟成一个磁盘后，Google Drive表示不支持这种文件系统（明明看属性是NTFS的），只能把内存做SSD的缓存了。

就不详细讨论配额了，用多许可的账号多开几个号，然后两边的团队盘都加这些账号权限就可以。
各种clone我就不用了，一旦出错，整理文件是场噩梦，而且主要是想实验这个模型。

买到的GCP账号普遍都给比较低的配额，而且没法调高（我自己开的就可以调高，只要发请求，一会儿就给通过）。用这个买到的账号最高只能开8C64G的机器。开Windows Server 2022，硬盘是50G SSD+ 199G SSD。然后下载了PrimoCache Server版，分了46G给硬盘加速。
开启Defer-write, 时间设置为永久。

我只登录了一个GD账号，然后用它在两个共享盘之间对拷。理想的情况是，从源盘往目标盘写入文件，然后写入完成后直接开始上传，传完后直接删了这个文件。只要缓存够大，就可以永远不用触发SSD读写，全在内存里进行。也就是形成一个完美的生产者-消费者模型。

经过我的测试，偶尔还是会短时间高密度读写磁盘，说明内存作为缓存满了。然后我设置了一下下载速度。再试试，好了很多。
理论上，如果内存能多一些，是可以实现几乎不读写磁盘的。
另外由于买的GCP账号最多只有8C，更高的带宽也无法勾选。所以如果是自己申请的账号，应该可以挑战一下更高的速度。
而GCP出站到Google Drive的流量是免费的，所以只需要支付虚拟机实例配置的费用，这个费用用免费的credit完全可以覆盖。
更大的内存，更高的带宽，对拷起来我感觉可以挑战一下500MB/s。
改天自己申请一个gcp账号再实验一下。