Changing Bitcask Expiry Policy

Martin Sumner martin.sumner at
Tue Jun 27 12:55:48 EDT 2017


I've not played around with this myself.  However, after a brief look at
the bitcask code, it looks like a timestamp is given to each object as it
is written to bitcask - to represent the time it was written, not the time
it will expire.  The expiry_time is part of the state of the bitcask
process passed on startup, and is not looked at during the PUT flow.

Bitcask checks to see if an object is expired when it is read (and also
when merging files), by comparing the write_time timestamp with the current
time (less the expiry time in seconds) - and the object is then deleted as
part of the GET operation.  So if the expiry time is disabled, these reads
will be forever valid once bitcask has that new state, as no knowledge of
the old expiry time is retained in the store. I don't think the object
itself has any sense of when it will expire, so I would expect that in your
case your data will be preserved.

I would recommend testing this before relying on my quick read through.




any hint on this question?

Felipe Esteves

felipe.esteves at
< at

Tel.: (21) 3504-7162 ramal 57162

Skype: felipe2esteves

2017-06-21 16:35 GMT-03:00 Felipe Esteves <felipe.esteves at <>>:

>* Hi,
*>>* If I have a Riak cluster with bitcask expiry turned on, let's say, 14
*>* days, and then change it to *bitcask.expiry=off* before any expiration
*>* occurs, all my data will be preserved? Or all data prior to the parameter
*>* change could still expiries based on the previous deadline?
*>>* Riak is version 2.2.3
*>>* thanks,
*>>* Felipe Esteves
*>>* Tecnologia
*>>* felipe.esteves at
< at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the riak-users mailing list