So lets list the options:

lvm2 new parameter:

1.) --cacheversion   1|2|auto

2.) --cache-metadata-version 2 ?

3.) --metadata-version 2  ?

4.) --cacheformat   1|2|auto    (or maybe this: v1|v2|auto ) ?


---

libdm API options:

1.) add new dm_tree_node_set_cache_version(....) 
2.) add new dm_tree_node_set_cache_format(....) 

3.) #define DM_CACHE_FEATURE_FORMAT_2 
4.) #define DM_CACHE_FEATURE_FORMAT_V2 
5.) #define DM_CACHE_FEATURE_VERSION_2 


---

ATM I'd prefer the format to be automatically recognized by the 'cache_check' tool - as adding some 'magical' args by lvm2 to the existing configurable set can be problematic for a user - it could be done - but lvm2 will be changing passed option set.

i.e. it's then unclear if we should use:

cache_check  --metadata-version 2

and also

cache_check  --metadata-version 1

or just use it with version 2 ?

---

Waiting for more judgment here.

So the upstream implementation uses:


lvcreate/lvconvert --cachemetadataformat auto|1|2  option to select format of cache metadata.

There is also support for metadata profile option:

allocation/cache_metadata_format   0|1|2    (0 == auto)

Expected usage is to pass this option while 'caching LV' - but it also work when you create cache-pool.

To see 'cachemetadataformat' in lvm2 metadata use: 'lvs -o+cachemetadataformat'
To see in-kernel format use: 'lvs -o+kernelmetadataformat' - but this is rather complementary function.

For cache-pool metadata format might be 'unselected'.
For actual cached LV it is always having value  1 or 2 (ATM).

For usage of metadata 2 format it's MANDATORY to have installed:
>= device-mapper-persistent-data-0.7.0-0.1.rc6