swift/doc/manpages/swift-object-updater.1

.\"
.\" Author: Joao Marcelo Martins <marcelo.martins@rackspace.com> or <btorch@gmail.com>
.\" Copyright (c) 2010-2012 OpenStack Foundation.
.\"
.\" Licensed under the Apache License, Version 2.0 (the "License");
.\" you may not use this file except in compliance with the License.
.\" You may obtain a copy of the License at
.\"
.\"    http://www.apache.org/licenses/LICENSE-2.0
.\"
.\" Unless required by applicable law or agreed to in writing, software
.\" distributed under the License is distributed on an "AS IS" BASIS,
.\" WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
.\" implied.
.\" See the License for the specific language governing permissions and
.\" limitations under the License.
.\"
.TH swift-object-updater 1 "8/26/2011" "Linux" "OpenStack Swift"

.SH NAME
.LP
.B swift-object-updater
\- OpenStack Swift object updater

.SH SYNOPSIS
.LP
.B swift-object-updater
[CONFIG] [-h|--help] [-v|--verbose] [-o|--once]

.SH DESCRIPTION
.PP
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
container listing.

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:

.RS 4
.PD 0
.IP "-v"
.IP "--verbose"
.RS 4
.IP "log to console"
.RE
.IP "-o"
.IP "--once"
.RS 4
.IP "only run one pass of daemon"
.RE
.PD
.RE


.SH DOCUMENTATION
.LP
More in depth documentation in regards to
.BI swift-object-updater
and also about OpenStack Swift as a whole can be found at
.BI https://docs.openstack.org/swift/latest/


.SH "SEE ALSO"
.BR object-server.conf(5)