Merge pull request #555 from dachary/master

minor documentation fixes

2 files changed, 16 insertions, 14 deletions

diff --git a/doc/dev/osd_internals/erasure_coding/pgbackend.rst b/doc/dev/osd_internals/erasure_coding/pgbackend.rst
index 4519ee34f9c..7b3b6f53326 100644
--- a/doc/dev/osd_internals/erasure_coding/pgbackend.rst
+++ b/doc/dev/osd_internals/erasure_coding/pgbackend.rst
@@ -79,10 +79,13 @@ Core Changes:
   APPEND, DELETE, (SET|RM)ATTR log entries.
 - The filestore needs to be able to deal with multiply versioned
   hobjects.  This probably means adapting the filestore internally to
-  use a vhobject which is basically a pair<version_t, hobject_t>.  The
-  version needs to be included in the on-disk filename.  An interface
-  needs to be added to get all versions of a particular hobject_t or
-  the most recently versioned instance of a particular hobject_t.
+  use a ghobject which is basically a tuple<hobject_t, gen_t,
+  shard_t>.  The gen_t + shard_t need to be included in the on-disk
+  filename.  gen_t is a unique object identifier to make sure there
+  are no name collisions when object N is created +
+  deleted + created again. An interface needs to be added to get all
+  versions of a particular hobject_t or the most recently versioned
+  instance of a particular hobject_t.
 
 PGBackend Interfaces:
 
@@ -178,7 +181,7 @@ acting set have different pieces of the erasure coding scheme and are
 not interchangeable.  Worse, crush might cause chunk 2 to be written
 to an osd which happens already to contain an (old) copy of chunk 4.
 This means that the OSD and PG messages need to work in terms of a
-type like pair<chunk_id_t, pg_t> in order to distinguish different pg
+type like pair<shard_t, pg_t> in order to distinguish different pg
 chunks on a single OSD.
 
 Because the mapping of object name to object in the filestore must
@@ -188,14 +191,14 @@ include the chunk id in the object key.
 
 Core changes:
 
-- The filestore `vhobject_t needs to also include a chunk id
+- The filestore `ghobject_t needs to also include a chunk id
   <http://tracker.ceph.com/issues/5862>`_ making it more like
-  tuple<hobject_t, version_t, chunk_id_t>.
-- coll_t needs to include a chunk_id_t.
+  tuple<hobject_t, gen_t, shard_t>.
+- coll_t needs to include a shard_t.
 - The `OSD pg_map and similar pg mappings need to work in terms of a
   cpg_t <http://tracker.ceph.com/issues/5863>`_ (essentially
-  pair<pg_t, chunk_id_t>).  Similarly, pg->pg messages need to include
-  a chunk_id_t
+  pair<pg_t, shard_t>).  Similarly, pg->pg messages need to include
+  a shard_t
 - For client->PG messages, the OSD will need a way to know which PG
   chunk should get the message since the OSD may contain both a
   primary and non-primary chunk for the same pg
diff --git a/src/mon/Paxos.h b/src/mon/Paxos.h
index 1bd3a3c1f51..764c4fee404 100644
--- a/src/mon/Paxos.h
+++ b/src/mon/Paxos.h
@@ -131,7 +131,7 @@ class Paxos;
  * This libary is based on the Paxos algorithm, but varies in a few key ways:
  *  1- Only a single new value is generated at a time, simplifying the recovery logic.
  *  2- Nodes track "committed" values, and share them generously (and trustingly)
- *  3- A 'leasing' mechism is built-in, allowing nodes to determine when it is 
+ *  3- A 'leasing' mechanism is built-in, allowing nodes to determine when it is 
  *     safe to "read" their copy of the last committed value.
  *
  * This provides a simple replication substrate that services can be built on top of.
@@ -325,8 +325,7 @@ private:
    *
    * Instead of performing a full commit each time a read is requested, we
    * keep leases. Each lease will have an expiration date, which may or may
-   * not be extended. This member variable will keep when is the lease 
-   * expiring.
+   * not be extended. 
    */
   utime_t lease_expire;
   /**
@@ -1091,7 +1090,7 @@ public:
    * onto paxos-related keys), and then we will decode those same bufferlists
    * we just wrote and apply the transactions they hold. We will also update
    * our first and last committed values to point to the new values, if need
-   * be. All all this is done tightly wrapped in a transaction to ensure we
+   * be. All this is done tightly wrapped in a transaction to ensure we
    * enjoy the atomicity guarantees given by our awesome k/v store.
    *
    * @param m A message