I looked into this when I was first using the cloud in order to apply CIS-hardened partition layouts. Long story short, messing with the root volume is simply not recommended. I came to the conclusion that given the 'cattle not pets' approach to the cloud, if something goes wrong I'll ditch the instance and deploy another fresh one, then investigate what ...
my understanding is that if you add additional PV (physical volume) to a VG (volume group) that hosts your LV (logical volume) you should be able to issue pvmove like so:
# Move a range of physical extents to a
# specific PV (which must have suffi‐
# cient free extents).
pvmove /dev/sdb1:1000-1999 /dev/sdc1
taken from man pvmove
dm-cache is a "slow moving" cache: many read/write misses are required to promote a block, especially when promoting a new block means to demote an already-cached one.
The fixed block-based nature of dm-cache, coupled with no reserved write-only area, means that many writes to the same non-cached blocks are required to trigger a block promotion/...