Update with correct external link for Ceph

README.md

@@ -42,7 +42,7 @@ Legend:
 ## Documented consistency
 
 * [Amazon S3](http://aws.amazon.com/s3/faqs/#What_data_consistency_model_does_Amazon_S3_employ) - buckets in the US Standard region provide eventual consistency.  Buckets in all other regions provide read-after-write consistency for PUTs of new objects and eventual consistency for overwrite PUTs and DELETEs.
-* [Ceph](http://ceph.com/papers/weil-rados-pdsw07.pdf) - provides well-defined safety semantics and strong consistency guarantees.
+* [Ceph](https://ceph.com/wp-content/uploads/2016/08/weil-rados-pdsw07.pdf) - provides well-defined safety semantics and strong consistency guarantees.
 * [Google Cloud Storage](https://cloud.google.com/storage/docs/concepts-techniques#consistency) - provides strong global consistency for all read-after-write, read-after-update, and read-after-delete operations, including both data and metadata.  List operations are eventually consistent.
 * [Microsoft Azure Storage](http://azure.microsoft.com/blog/2014/09/08/managing-concurrency-in-microsoft-azure-storage-2/) - was designed to embrace a strong consistency model which guarantees that when the Storage service commits a data insert or update operation all further accesses to that data will see the latest update.
 * [OpenStack Swift](http://docs.openstack.org/developer/swift/overview_architecture.html#updaters) - For example, suppose a container server is under load and a new object is put in to the system. The object will be immediately available for reads as soon as the proxy server responds to the client with success. However, the container server did not update the object listing, and so the update would be queued for a later update. Container listings, therefore, may not immediately contain the object.  [Additional reference](http://lists.openstack.org/pipermail/openstack-dev/2014-June/038881.html).