Description of problem:

case 02666248 needed the ability to reduce the metadata LV for pools on a large number of servers. Since this was not possible through lvreduce, we took the following approach.

1) deactivate the pool and all its thin lv's using lvchange -an vgname/lvname
2) create a new 15gb lv in the same VG using lvcreate -L15gb -n newmeta vgname
3) Activate the pool's metadata in readonly mode using lvchange -ay vgname/poolname_tmeta (answer "y")
4) thin_repair -i /dev/mapper/vgname-poolname_tmeta -o /dev/mapper/vgname-newmeta
5) Deactivate the metadata you had activated in step 3, using lvchange -an /dev/mapper/vgname-poolname_tmeta

6) swap back the metadata from newmeta using lvconvert --thinpool vgname/poolname --poolmetadata /dev/mapper/vgname-newmeta (answer "y")
7) Activate the pool and all its thinlv's in the vg using vgchange -ay vgname

This worked, and the customer was able to reduce the metadata size without having to destroy and re-create the pools.

This can be automated to have a new tool called thin_metadata_shrink , and tied into lvreduce so lvm can allow reduction of the pool_tmeta lv.

Actual results:
thin pool metadata lv cannot be reduced today with lvreduce.

Expected results:
lvreduce should be able to reduce the size of the metadata.

Additional info:
This is very useful for customers who have pools created that are using 16gb sized metadata (for eg, due to 1gb extent sizes) and want to reduce it because they end up vulnerable to https://bugzilla.redhat.com/show_bug.cgi?id=1441153