anchor.diff:  
   Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a pod.  For those volumes that support multiple access modes, the user specifies which mode desired when using their claim as a volume in a pod.
   
  -Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as she needs it. Users schedule Pods and access their their claimed PVs by including a persistentVolumeClaim in their Pod's volumes block. [See below for syntax details](#claims-as-volumes).
  +Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as she needs it. Users schedule Pods and access their claimed PVs by including a persistentVolumeClaim in their Pod's volumes block. See link:#claims-as-volumes[below] for syntax details.
   
   === Releasing
   
  -When a user is done with their volume, they can delete the PVC objects from the API which allows reclamation of the resource.  The volume is considered "released" when the claim is deleted, but it is not yet available for another claim.  The previous claimant's data remains on the volume which must be handled according to policy.
  +When a user is done with a volume, they can delete the PVC object from the API which allows reclamation of the resource.  The volume is considered "released" when the claim is deleted, but it is not yet available for another claim.  The previous claimant's data remains on the volume which must be handled according to policy.
   
   === Reclaiming
   
  -A `PersistentVolume's` reclaim policy tells the cluster what to do with the volume after it's released.  Currently, volumes can either be Retained or Recycled.  Retention allows for manual reclamation of the resource.  For those volume plugins that support it, recycling performs a basic scrub ("rm -rf /thevolume/*") on the volume and makes it available again for a new claim.
  +The reclaim policy of a `PersistentVolume` tells the cluster what to do with the volume after it's released.  Currently, volumes can either be Retained or Recycled.  Retention allows for manual reclamation of the resource.  For those volume plugins that support it, recycling performs a basic scrub ("rm -rf /thevolume/*") on the volume and makes it available again for a new claim.
   
   == Persistent Volumes
   
   == Types of Persistent Volumes
   
  -`PersistentVolume`s are implemented as plugins.  OpenShift currently supports the following plugins:
  +OpenShift currently supports the following `PersistentVolume` plugins:
   
   * NFS
   * GCEPersistentDisk
   * AWSElasticBlockStore
  +* HostPath (single node testing only)
  +
  +More plugins are available but still under development:
  +
   * Glusterfs
   * iSCSI
   * RBD (Ceph Block Device)
  -* HostPath (single node testing only)
   
   Each PV contains a spec and status, which is the specification and status of the volume.
   
  
positive.code: 
  === Capacity
  
  Generally, a PV will have a specific storage capacity.  This is set using the PV's `capacity` attribute.  See the Kubernetes [Resource Model](./resources.md) to understand the units expected by `capacity`.
  
  Currently, storage size is the only resource that can be set or requested.  Future attributes may include IOPS, throughput, etc.
  
  === Access Modes
  
  
negative.code: 
  === Resources
  
  Claims, like pods, can request specific quantities of a resource.  In this case, the request is for storage.  The same link:https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/resources.md[resource model] applies to both volumes and claims.
  
  === Claims As Volumes
  
  