1. 03 6月, 2012 1 次提交
    • J
      dm thin: provide userspace access to pool metadata · cc8394d8
      Joe Thornber 提交于
      This patch implements two new messages that can be sent to the thin
      pool target allowing it to take a snapshot of the _metadata_.  This,
      read-only snapshot can be accessed by userland, concurrently with the
      live target.
      
      Only one metadata snapshot can be held at a time.  The pool's status
      line will give the block location for the current msnap.
      
      Since version 0.1.5 of the userland thin provisioning tools, the
      thin_dump program displays the msnap as follows:
      
          thin_dump -m <msnap root> <metadata dev>
      
      Available here: https://github.com/jthornber/thin-provisioning-tools
      
      Now that userland can access the metadata we can do various things
      that have traditionally been kernel side tasks:
      
           i) Incremental backups.
      
           By using metadata snapshots we can work out what blocks have
           changed over time.  Combined with data snapshots we can ensure
           the data doesn't change while we back it up.
      
           A short proof of concept script can be found here:
      
           https://github.com/jthornber/thinp-test-suite/blob/master/incremental_backup_example.rb
      
           ii) Migration of thin devices from one pool to another.
      
           iii) Merging snapshots back into an external origin.
      
           iv) Asyncronous replication.
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      cc8394d8
  2. 29 3月, 2012 1 次提交
    • M
      dm thin: relax hard limit on the maximum size of a metadata device · c4a69ecd
      Mike Snitzer 提交于
      The thin metadata format can only make use of a device that is <=
      THIN_METADATA_MAX_SECTORS (currently 15.9375 GB).  Therefore, there is no
      practical benefit to using a larger device.
      
      However, it may be that other factors impose a certain granularity for
      the space that is allocated to a device (E.g. lvm2 can impose a coarse
      granularity through the use of large, >= 1 GB, physical extents).
      
      Rather than reject a larger metadata device, during thin-pool device
      construction, switch to allowing it but issue a warning if a device
      larger than THIN_METADATA_MAX_SECTORS_WARNING (16 GB) is
      provided.  Any space over 15.9375 GB will not be used.
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      c4a69ecd
  3. 01 11月, 2011 1 次提交
    • J
      dm: add thin provisioning target · 991d9fa0
      Joe Thornber 提交于
      Initial EXPERIMENTAL implementation of device-mapper thin provisioning
      with snapshot support.  The 'thin' target is used to create instances of
      the virtual devices that are hosted in the 'thin-pool' target.  The
      thin-pool target provides data sharing among devices.  This sharing is
      made possible using the persistent-data library in the previous patch.
      
      The main highlight of this implementation, compared to the previous
      implementation of snapshots, is that it allows many virtual devices to
      be stored on the same data volume, simplifying administration and
      allowing sharing of data between volumes (thus reducing disk usage).
      
      Another big feature is support for arbitrary depth of recursive
      snapshots (snapshots of snapshots of snapshots ...).  The previous
      implementation of snapshots did this by chaining together lookup tables,
      and so performance was O(depth).  This new implementation uses a single
      data structure so we don't get this degradation with depth.
      
      For further information and examples of how to use this, please read
      Documentation/device-mapper/thin-provisioning.txt
      Signed-off-by: NJoe Thornber <thornber@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      991d9fa0