I threw a simple smoke test on it: walk a directory tree and store each regular file in the tree in the data storage thing. The directory tree wasn't anything radical - just 112MB, 260 keys/values, biggest one was 10MB. Then close the storage thing, open it again and see if we can retrieve the contents. No concurrency, no crash recovery, nothing. Sure, maybe not exactly a typical workload, but let's see how things behave at the extremes first. They do talk about big keys in the blog post.

First impression. Easy to write the code.

Second impression. Fast as hell.

Third impression. Loses data. The last file in the set is consistently corrupted no matter how many times I try. I also tried on different directories. Exact same result everywhere. Last key/value written is truncated.

Hmm. A data storage thing that fails to store data is maybe not exactly invoking feelings of trust, which should be the primary feelings you have about your data storage thing.

Let's just throw it on something bigger. My /usr/lib. It's just 1.4GB. Shouldn't be too hard.

    [ 6546.783474] Killed process 4895 (main) total-vm:497120kB, anon-rss:368384kB, file-rss:0kB, shmem-rss:0kB

Hmm. Do they just store everything in memory forever? Sure, this VM has stupidly little memory. But that's why we have disk. So that we don't have to keep everything in memory. But good. Now we get to test the crash recovery mechanism.

    [ 6823.635967] Killed process 4919 (main) total-vm:677964kB, anon-rss:367980kB, file-rss:0kB, shmem-rss:0kB

Right. I guess there are reasons why experience taught me to let others be the first to use new data storage technology for a few years.

In case someone wonders the test code is here: https://gist.github.com/art4711/9d781b8cf1f9f36df73a9c5c0403...

It may be all wrong, but considering that the "docs" directory contains 6MB of stuff just to display "hello world" twice, I had to write it based on what godoc said.

user:	swedrupe
created:	October 5, 2016
karma:	3