Code (not exposed) exists to save the cache policy name and its parameters in LVM metadata. The current format to do this is as an "argv" style array encoded in a space-separated string. A more idiomatic (and structured) way to go about this would be to add a section to the LV stanza -- by a section I mean this:

cache_policy {
    param1 = "value1"
    param2 = "value2"
}

The config parser will happily work with this format, it captures the structure of the data (key-value pairs, with unstructured values) and is just as (if not more) future-proof as a string would be. The expectation is that all these parameters are serialised back into the argv-style array when passed into the kernel. This means we need to take care not to allow whitespace inside the values. Another restriction is that LVM should (at least for now) not interpret the cache_policy section, other than parsing/formatting the key-value relationships in the metadata form and in the kernel form. This is easily doable with the current config parser.

The CLI side of things needs to be drafted up. It is unrealistic to have dm-persistent-data provide us with the admissible key/value pairs (i.e. validation of parameters) at this time. This might change in the future.

To allow users to manipulate the parameters, we would add an 'lvchange' flag (say, --cachepolicy) that would take the parameters in some suitable format on the commandline. If we allow repeats, it might be something like:

lvchange --cachepolicy param1=value1 --cachepolicy param2=value2 LV

(the alternative would be to allow only one --cachepolicy and take the param=value pairs comma-separated; I personally like the multi-arg variant better)

The main reason for extending lvchange with this (but not lvcreate or lvconvert) is validation: we don't want to store "bogus" metadata only to find out it is bogus at activation time (which may or may not be much later). With lvchange, we can restrict the users to change policy only on active cache LVs, and obtain the current (default) keys and values from the kernel. We can therefore validate at least the key names and if the values that are provided by the user turn out to be wrong, we could (at least in principle) fail gracefully before writing the (bogus) policy parameters into metadata.

When a better method for validating the parameters becomes available, we may add --cachepolicy to lvcreate and lvconvert as appropriate.

After talking this through, we have the following consensus on --cachepolicy:

1) the argument to --cachepolicy will be a 'config tree', the same data type that
   --config currently uses
2) 'config tree' can be currently specified in the format
   'section { key1 = foo key2 = bar; }' -- we will extend this to use the
   more streamlined and CLI-friendly form 'section/key1=foo'
   (applies to both --cachepolicy and --config)
3) both --cachepolicy and --config will be made to 'cascade' within the 
   commandline; that is, --config a/b=x --config a/c=y will result in
   'a { b=x c=y }' (currently this is not the case and one of the values
   is entirely dropped instead)

This approach also separates commandline parsing from parameter validation, so in the future, we can substitute another validation approach without seriously breaking things. On the validation side, the current preference is to simply hard-code the list of policies and their options currently available in dm_cache in LVM. This would make it possible to also allow --cachepolicy with lvcreate and lvconvert, if we require that validation will always be possible ahead of time.

Some code got added to lvchange recently, but similar changes still needed to lvcreate/lvconvert.

Yes, lvchange is covered since c75ae0846e4c1a74fbd44d85837e2b6dc50e9783. Setting the options upon creation will use the same syntax/mechanism. Reporting may need to be sorted out too (currently only available via dmsetup AFAIK).

Added lvcreate in 5b2726fc6142c734e06fa8b49ad856b2e47da9fc, still missing: lvconvert, reporting.

The code for reporting cache policy and cache settings (with `lvs`) is in upstream commit 00ad13eb719607682dfcf17d99ad96cfd5603d14. This means lvcreate and lvchange can be used to change policy and policy settings, `lvs` has fields to report those (cache_policy and cache_settings, to mirror --cachepolicy and --cachesettings parameters). What remains is to add --cachepolicy and --cachesettings to `lvconvert` -- I'll create a separate BZ for that, as it's not a requirement for this BZ (even if a cache LV comes into existence via `lvconvert`, the policy can easily be tweaked by a followup `lvchange`).

We've discovered a few problems with patch from comment #7, these patches are required in addition:


https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=f6f32f39e4ef007fd8566fe32c00975f917fc807

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=da9da0d8c2201c244d06a713134e96d2a26a0db5

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=57af48d734f1f7aa985424a1e11287a0975077b9

I'll add that in today's new build.

To QA: some info about cache policies and their settings:
https://www.kernel.org/doc/Documentation/device-mapper/cache-policies.txt

Changed default sequential_threshold to 256 from the default 512 to trigger the display of the custom value in lvs. 

[root@tardis-03 ~]# lvchange vg/origin --cachesettings sequential_threshold=256
  Logical volume "origin" changed.

[root@tardis-03 ~]# lvs -aolv_name,cache_policy,cache_settings,cachemode
  LV              Cache Policy Cache Settings           Cachemode   
  home                                                              
  root                                                              
  swap                                                              
  [cache0]                                              writethrough
  [cache0_cdata]                                                    
  [cache0_cmeta]                                                    
  [lvol0_pmspare]                                                   
  origin          mq           sequential_threshold=256 writethrough
  [origin_corig]                                                    
[root@tardis-03 ~]# 


More details regarding the settings and cache policies can be found in kernel device-mapper documentation:

https://www.kernel.org/doc/Documentation/device-mapper/cache-policies.txt


Marking this as VERIFIED with:

lvm2-2.02.115-2.el7.x86_64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0513.html