Its HTTP fastcgi frontend got ability to request statistics from remote nodes and tell clients whether things are good or not. In particular it is able to return XML with CPU and memory usage stats and filesystem data (total and available size, number of files if supported and FSID).

Here are fastcgi (lighttpd) config options:

# request remote nodes statistics
# plain stat will request stats and return 200 status if either
# number of received replies is more than $DNET_FCGI_STAT_BAD_LIMIT (if set)
# or is more than number of bad replies
"DNET_FCGI_STAT_PATTERN_URI" => "/stat",

# this will always return 200 status with XML data showing node statistics:
# CPU and memory usage and filesystem data (total and available sizes, FSID and number of files)
# if such statistics is supported
"DNET_FCGI_STAT_LOG_PATTERN_URI" => "/stat_log",

# plain stat request will return 400 status when number of bad replies returned from the
# storage is more than this number or when number of good replies is less than that.
# It is not used when log statistics is requested.
"DNET_FCGI_STAT_BAD_LIMIT" => "1",

Next task is to actually implement virtual datacenters split via hash functions. This idea is described on elliptics network homepage. This will allow not only to split copies into different datacenters, but also implement special caching nodes, which will be mapped by additional hash function, so that some popular content could be fetched not from the main cloud but from those dedicated nodes, it can be controlled on per-address basis for example.

And the main idea is background fsck. The more I think about it the more I like idea when node does not copy content when joining to the network and instead that background fsck task will do the work, there is a fair number of problems with content sync during joining, which will fire up when we will sync 10 Tb of data from one machine to another (those numbers we talked about recently). Well, 'empty' joined node will not return data (until it is copied there), so client will request it from backup copy, but there will be no need to postpone writes.

Another idea about background fsck is special log it can use to fetch data, which will contain all objects written with its IDs, so it would not ask every single object whether its copy exists or not, but only process those ones which are presented in the log. This is a client responsibility to write one though, for example it can be formatted from POST access logs from HTTP frontend proxy.

That's the plan, stay tuned!