Eventual consistency model
An eventual consistency model is used when uploading or deleting object data.
According to the CAP theorem, in distributed storage systems, a system can guarantee two of the following three claims:
- Consistency
- Availability
- Partition tolerance
With Swift and IBM Spectrum Scale™ for object storage, the availability and partition tolerance claims are chosen. Therefore, in some cases, it is possible to get an inconsistent listing of object store contents. The most common case is consistency between container listing databases and objects on disk. In the case of a normal object upload, the object data is committed to the storage and the container listing database is updated. Under heavy load, it is possible that the container listing database update does not complete immediately. In that case, the update is made asynchronously by the object-updater service. In the time between the original object commit and when the object-updater executes, you will not see the new object in the container listing, even though the object is safely committed to storage. A similar situation can occur with object deletes.