- Be clearer about what the effects of the damage are.
       eg, This thin volume is lost.  The mappings in this logical range
           are lost, there were 'n' mapped blocks in this region.

   thin_rmap tool written, just need cross referencing with LVM
   metadata to identify the LVs.

- Handle out of data space gracefully
  - Configure a set of thins that may be purged?

- Handle out of metadata space gracefully
  - Automate recovery in the case of damaged pool metadata

  Need to produce a set of scenarios (eg, transaction ids mismatch
  after recovery, differing nrs of thins, missing data).

- Make sure recovery works at all levels in our supported stacks list.
  eg, RAID recovery if a leg of the data volume is lost.

- Any thin volumes that have been recovered but have potentially
  lost blocks should be marked as such.

- Any completely lost thin volumes should be recreated empty, but
  marked as damaged.

  Alternatively delete them (which is what current lvm does for
  non-thin).  Decide.

- Damaged thins should report how much space was allocated at the
  time of recovery.

- The admin should be able to delete all damaged thins with a simple
  command line.  (similar to --removemissing).

- Work around transient failures of underlying PV/LV
  - We should be able to activate the pool and any thin volumes
    that are not provisioned on these failed PV/LVs.
  - We should be able to activate thins that *do* have allocations
    on the failed PV/LVs at the admins request.  This will mark the
    thins as damaged.  (Punch error targets into the pool).


** It is very likely that this will be broken-up further into more bugs.**