The object updater is responsible for updating object information in container listings.
It will check to see if there are any locally queued updates on the filesystem of each
devices, what is also known as async pending file(s), walk each one and update the
For example, suppose a container server is under load and a new object is put
into the system. The object will be immediately available for reads as soon as
the proxy server responds to the client with success. However, the object
server has not been able to update the object listing in the container server.
Therefore, the update would be queued locally for a later update. Container listings,
therefore, may not immediately contain the object. This is where an eventual consistency
window will most likely come in to play.
In practice, the consistency window is only as large as the frequency at which
the updater runs and may not even be noticed as the proxy server will route
listing requests to the first container server which responds. The server under
load may not be the one that serves subsequent listing requests – one of the other
two replicas may handle the listing.
The options are as follows:
only run one pass of daemon