johnnydepp

我感觉楼主可能没有女朋友...

这还好是 linode，如果是腾讯云或者阿里云的云盘是这种性能表现，还不被 V2 上的喷子喷死啊。为什么一直到今天国内企业还是享受不到正常国民待遇呢。

这个问题要分技术上和商业上两个来考虑，如果是技术上的，不管你的数据放在哪里，就算你藏在你家被子里，也会被人窃取走。但是商业角度来看，大的公有云服务商盗取你的数据，相比整个公有云市场而言，你的数据的商业价值实在是不值得一提。人家不会因小失大的，放心吧。

再说了，你在微信上那么多的聊天记录，全在腾讯的服务器上，后台开发都能看到你的内容，你担心吗：）

这个应该是产品定义上就没有保证吧，不过这个盘也是最便宜的，一分价格一分货，走到哪里都没错。即使你买 AWS 的第一代磁介质云盘，也没有性能保障的。
不过腾讯这个只有 100iops，也确实太低了点，虽然你没有 SLA 承诺，但也不意味着你可以这么大胆的肆意妄为啊。

@bachbear 你们是用的哪家的机器啊？

转内用了，对外业务逐步都砍掉了。

这文章的专业性真是不敢苟同，既然做性能测试，连各个厂商用的什么类型的实例、什么类型的磁盘都不写，测试工具也是私有的，测试方法也没有披露，这样推导出来的测试结果怎么能让人信服。AWS 有四种 EBS 云盘，最高有 500MB 吞吐，这里随便测了个几十 MB 就说 AWS 的磁盘读写吞吐是最大弱项，未免也太搞笑了。

@johnnydepp
继续转载：
cOnv=fsync Synchronize output data and metadata just before finishing 意思也就是在 dd 命令结束前同步 data 和 metadata，那就是不是每一次写都同步一次咯，就是如果我们在 dd 命令中写了 100 次，他可能是等到最后的时候才把他们同步到磁盘。而 oflag=dsync 是说 Use synchronized I/O for data. For the output file, this forces a physical write of output data on each write，注意这里边用词 a physical write of output data on each write,那就是他是每一次写都得等到这一次写写到了磁盘才进行下一个写，也就是如果我们使用 dd 写 100 次，他每次写都是写到磁盘后才进行下一次写的。所以这样当然要比 cOnv=fsync 慢一些吧。

纯转载：
Ways in which you can invoke 'dd' to test the write speed:
dd bs=1M count=256 if=/dev/zero of=test
dd bs=1M count=256 if=/dev/zero of=test; sync
dd bs=1M count=256 if=/dev/zero of=test cOnv=fdatasync
dd bs=1M count=256 if=/dev/zero of=test oflag=dsync
What is the difference between those?
dd bs=1M count=256 if=/dev/zero of=test
The default behaviour of dd is to not “ sync ” (i.e. not ask the OS to completely write the data to disk before dd exiting). The above command will just commit your 128 MB of data into a RAM buffer (write cache) this will be really fast and it will show you the hugely inflated benchmark result right away. However, the server in the background is still busy, continuing to write out data from the RAM cache to disk.
dd bs=1M count=256 if=/dev/zero of=test; sync
Absolutely identical to the previous case, as anyone who understands how *nix shell works should surely know that adding a ; sync does not affect the operation of previous command in any way, because it is executed independently, after the first command completes. So your (inflated) MB/sec value is already printed on screen while that sync is only preparing to be executed.
dd bs=1M count=256 if=/dev/zero of=test cOnv=fdatasync
This tells dd to require a complete “ sync ” once, right before it exits. So it commits the whole 256 MB of data, then tells the operating system: “ OK, now ensure this is completely on disk ”, only then measures the total time it took to do all that and calculates the benchmark result.
dd bs=1M count=256 if=/dev/zero of=test oflag=dsync
Here dd will ask for completely synchronous output to disk, i.e. ensure that its write requests don ’ t even return until the submitted data is on disk. In the above example, this will mean sync'ing once per megabyte, or 256 times in total. It will be the slowest mode, as the write cache is basically unused at all in this case.