Kelly has an interesting post about memory-mapped files and the cloud. This is in response to a comment on my post where I stated that we don’t reserve space up front in Voron because we  support cloud providers that charge per storage.

From Kelly’s post, I assume she thinks about running it herself on her own cloud instances, and that is what her pricing indicates. Indeed, if you want to get a 100GB cloud disk from pretty much anywhere, you’ll pay for the full 100GB disk from day one. But that isn’t the scenario that I actually had in mind.

I was thinking about the cloud providers. Imagine that you want to go to RavenHQ, and get a database there. You sign up for a two GB plan, and all is great. Except that, on the very first write, we allocate a fixed 10 GB, and you start paying overage charges. This isn’t what you pay when you run on your own hardware. This is what you would have to deal with as a cloud DBaaS provider, and as a consumer of such a service.

That aside, let me deal a bit with the issues of memory-mapped files and sparse files. I created six sparse files, each of them 128 GB in size, in my E drive.

As you can see, this is a 300 GB disk, but I just “allocated” 640GB of space in it.

This also shows that there has been no reservation of space on the disk. In fact, it is entirely possible to create files that are entirely too big for the volume they are located on.

I did a lot of testing with MMAP files and sparseness, and I came to the conclusion that you can’t trust it. You especially can’t trust it in a cloud scenario.

But, why? Well, imagine a scenario where you need to use a new page, and the file system needs to allocate one for you. At this point, it needs to find an available page. That might fail, and let's imagine that this fails because there's no free space, because that is easiest.

What happens then? Well, you aren’t accessing things via an API, so there isn’t an error code it can return or an exception to be thrown.

In Windows, it will use the standard exception handler to throw the error. In Linux, that will probably generate a SIVXXX error. Now, to make things interesting, this may not actually happen when you are writing to the newly reserved page, it may be deferred by the OS to a later point in time (or if you call msync or FlushViewOfFile).  At any rate, that means that at some point the OS is going to wake up and realize that it promised something it can’t deliver, and in that point (which, again, may be later than the point you actually wrote to that page) you are going to find yourself in a very interesting situation. I’ve actually tested that scenario, and it isn’t a good one form the point of view of reliability. You really don’t want to get there, because then all bets are off with regards to what happens to the data you wrote. And you can’t even do graceful error handling at that point, because you might be past the point.

Considering the fact that a full disk is one of those things that you really need to be aware about, you can’t really trust this intersection of features.