Dne 15.2.2017 v 14:30 Jonas Degrave napsal(a):
Thanks, I tried your suggestions, and tried going back to the mq policy and
play with those parameters. In the end, I tried:
lvchange --cachesettings 'migration_threshold=20000000
With little success. This is probably due to the mq-policy looking only at the
hit-count, rather than the hit-rate. Or at least, that is what I make up from
line 595 in the code:
I wrote a small script, so my users could empty the cache manually, if they
if [ "$(id -u)" != "0" ]; then
echo "This script must be run as root" 1>&2
lvremove -y VG/lv_cache
lvcreate -L 445G -n lv_cache VG /dev/sda
lvcreate -L 1G -n lv_cache_meta VG /dev/sda
lvconvert -y --type cache-pool --poolmetadata VG/lv_cache_meta VG/lv_cache
lvchange --cachepolicy smq VG
lvconvert --type cache --cachepool VG/lv_cache VG/lv
So, the only remaining option for me, would to write my own policy. This
should be quite simple, as you basically need to act as if the cache is not
Can someone point me in the right direction as to how to do this? I have tried
to find the last version of the code, but the best I could find was a redhat
CVS-server which times out when connecting.
cvs -d :pserver:c...@sources.redhat.com:/cvs/dm login cvs
cvs [login aborted]: connect to sources.redhat.com
<http://sources.redhat.com>(220.127.116.11):2401 failed: Connection timed
Can someone direct me to the latest source of the smq-policy?
Yep - it does look like you have some special use-case where you know 'ahead
of time' what's the usage pattern going to be.
'smq' policy is targeted to rather 'slowly' fill over the time with 'more time
permanent data' which are known to be kept used over and over - so i.e. after
reboot there is large chance you will need them again.
But in your case it seems you need a policy which fills very quickly with
current set of date - i.e. some sore of page-cache extension.
So to get to the source:
relatively 'small' piece of code - by may take a while to get to it as you
need to fit within policy rules - there is certain limited amount of data you
may keep with cached data block and some others...
Once you get new dm caching policy loaded - lvm2 should be able to use it,
as cache_policy & cache_settings are 'free-from' strings.
For 4.12 kernel (likely) there is going to be new 'cache2-like' which should
be match faster with startup... but likely it may or may not solve your
special 100GB workload.
linux-lvm mailing list
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/