7

crucially # in bitcask if you do a HEAD request does it need to find the 
object on disk and read it in?

seancribbs # crucially: with any of the backends, yes. there's no separation of metadata from object

crucially # ok

seancribbs # so the only savings you get is over the wire to your application

crucially # so storing riakfs metadata in another bucket and store that bucket on SSD
is a sensible idea

seancribbs # other than possibly needing more than one request to store, yeah

crucially # the only thing you need to do is update mtime when you write
and you could do that in a post commit hook
is there any way to get sub second time resolution?

seancribbs # erlang:now() returns micros i believe
http://erldocs.com/R13B04/erts/erlang.html?search=now&i=4#now/0

crucially # but not over http?

seancribbs # no, because the HTTP date format doesn't support sub-second

crucially # could add a X-Riak-Date or something

seancribbs # yeah could do that in pre-commit even

crucially # the http date format is retarded

seancribbs # agreed

crucially # do you store the etag or do you calculate in on the fly?

seancribbs # I believe it's calculated in the http resource it's just an md5 of the vclock

crucially # oki