Because there's an extra virtual layer between you and the hard-disk, fsync() does not do what it says it does, which means that a database cannot actually guarantee that a transaction was successfully completed.

In case your traffic is huge, this can cause big problems that are very hard to fix. And it did cause problems for Reddit, as EBS is notoriously awful in this regard (and others, like big latencies on access).

Basically when working at big scales, nothing beats having complete control over your infrastructure. It may be tough and time consuming, but at least you can identify the problem and fix it.

It is my opinion that something like Google's search cannot be built on top of Amazon's AWS.

Saying that because fsync() doesn't work in AWS that it won't work 'in the cloud' is much like saying that because you can't take a cheap sedan to the bush that a 4wd can't possibly exist.

Google can't exist (well) on top of AWS as AWS is designed for the deployment of (qusi)stateless applications. Saying that you can't build a data intensive application on top of it is like saying that your machinegun sucks at grating cheese.

OVM was designed to run a search engine origionally (darkmatr, now defunct due to lack of comparitive profitability), so you could quite easily build google on top of it. It wouldn't surprise me if google would work really well on top of that stack.

It seems that (at least for AWS) EBS might not always do what you expect with fsync()

http://teddziuba.com/2011/04/amazon-the-purpose-of-pain.html

In the way that you have no idea whether fsync actually writes the data to disk, or whether it puts it in memory somewhere (usually a write cache).

Most modern hard drives don't actually do what most people expect an fsync does anyway. This is an interesting thread about Apple's F_FULLFSYNC ioctl that discusses the problem (this pat is by Apple FS engineer Dominic Giampaolo): http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072...