+ * Good question. Without some kind of versioning with a global counter
+ * it is not possible to have trasactions on disk, but they are still
+ * useful since from the point of view of memory and client bugs it is
+ * a protection anyway. Also it's useful for WATCH.
+ *
+ * Btw there is to check what happens when WATCH gets combined to keys
+ * that gets removed from the object cache. Should be save but better
+ * to check.
+ *
+ * - Check if/why INCR will not update the LRU info for the object.
+ *
+ * - Fix/Check the following race condition: a key gets a DEL so there is
+ * a write operation scheduled against this key. Later the same key will
+ * be the argument of a GET, but the write operation was still not
+ * completed (to delete the file). If the GET will be for some reason
+ * a blocking loading (via lookup) we can load the old value on memory.
+ *
+ * This problems can be fixed with negative caching. We can use it
+ * to optimize the system, but also when a key is deleted we mark
+ * it as non existing on disk as well (in a way that this cache
+ * entry can't be evicted, setting time to 0), then we avoid looking at
+ * the disk at all if the key can't be there. When an IO Job complete
+ * a deletion, we set the time of the negative caching to a non zero
+ * value so it will be evicted later.
+ *
+ * Are there other patterns like this where we load stale data?
+ *
+ * Also, make sure that key preloading is ONLY done for keys that are
+ * not marked as cacheKeyDoesNotExist(), otherwise, again, we can load
+ * data from disk that should instead be deleted.
+ *
+ * - dsSet() should use rename(2) in order to avoid corruptions.
+ *
+ * - Don't add a LOAD if there is already a LOADINPROGRESS, or is this
+ * impossible since anyway the io_keys stuff will work as lock?
+ *
+ * - Serialize special encoded things in a raw form.
+ *
+ * - When putting IO read operations on top of the queue, do this only if
+ * the already-on-top operation is not a save or if it is a save that
+ * is scheduled for later execution. If there is a save that is ready to
+ * fire, let's insert the load operation just before the first save that
+ * is scheduled for later exection for instance.
+ *
+ * - Support MULTI/EXEC transactions via a journal file, that is played on
+ * startup to check if there is cleanup to do. This way we can implement
+ * transactions with our simple file based KV store.