[TriLUG] lvm2 cache-pool backported to Ubuntu 14.04?

David Both via TriLUG trilug at trilug.org
Fri May 1 11:44:39 EDT 2015


You don't say, but how much RAM do the physical hosts currently have? It is most 
likely that, if you have low physical RAM on the hosts, the hosts are thrashing 
while they try to keep active virtual memory in RAM, but there is just too 
little. More RAM would be a lot less expensive than SSD's. If you don't have 
enough RAM the SSD's will simply afford faster swapping so you might see some 
improvement, but not have resolved the root cause of the problem.


On 05/01/2015 10:44 AM, Cristóbal Palmer via TriLUG wrote:
> Greetings LUG folks,
>
> I have some developer workstations that have dev/test VMs on them, and we're
> experiencing disk I/O that bogs these machines down whenever a workstation has
> more than two guests. We are in the process of acquiring 128GB SSDs, and this
> post is asking about a specific strategy for using those SSDs to speed up the
> machines for our use case.
>
> To simplify, let's say we have the following (close enough to the truth):
>
>    $ sudo pvs
>      PV         VG    Fmt  Attr PSize   PFree
>      /dev/md0   boot  lvm2 a--  900.00m 100.00m
>      /dev/md1   knuth lvm2 a--  500.00g 120.00g
>      /dev/sdc1  knuth lvm2 a--  115.38g  34.24g
>
> and that /dev/md0 and /dev/md1 are a raid 1 array of two slow 500GB disks,
> while /dev/sdc is the new SSD. What I'd like to do is use the cache-pool in
> a manner something like Richard Jones and others discussed last year on the
> linux-lvm list[0].
>
> To that end, I've made two logical volumes:
>
>    $ sudo lvs |grep cache
>      lv_cache                     knuth -wi-a----  62.00g
>      lv_cache_meta                knuth -wi-a----  64.00m
>
> ... and attempted to set them up as a cache pool:
>
>    $ sudo lvconvert --type cache-pool \
>    --poolmetadata knuth/lv_cache_meta knuth/lv_cache
>      WARNING: Unrecognised segment type cache-pool
>
> What some quick investigation makes clear is that my lvm2 is too old:
>
>    $ dpkg -l lvm2 | grep ^ii
>    ii  lvm2     2.02.98-6ubuntu2      amd64    Linux Logical Volume Manager
>
> More searching shows some people willing to install lvm2 from source. We're
> not an org where that's going to fly, and I'd rather not be in the business of
> maintaining an lvm2 backport. Does anybody have experience getting this sort of
> thing to work on Ubuntu 14.04? Did you for example use a backported package
> from Vivid Vervet[1][2]? If so, what were your steps? How do you do maintenance
> updates?
>
> We have workstations running Debian 8.0, CentOS 7, Ubuntu 14.04 and CentOS 6.6,
> so solutions that abandon Ubuntu are something I'm happy to see people write to
> the list about, but remember that my priorities are such that using packages
> that are easily pulled from a reputable upstream without needing to do a local
> build are strongly preferred. I could hopefully have this working today if I
> were willing to abandon that and just build lvm2 from source, but that possibly
> sacrifices repeatability and maintainability for our office.
>
> Cheers and thanks,
> --
> Cristóbal Palmer
> ibiblio.org
>
>
> [0] https://www.redhat.com/archives/linux-lvm/2014-May/msg00037.html
> [1] https://launchpad.net/ubuntu/+source/lvm2
> [2] https://launchpad.net/ubuntu/+source/lvm2/2.02.111-2ubuntu1
>
> -- 
>
>
> *********************************************************
> David P. Both, RHCE
> Millennium Technology Consulting LLC
> Raleigh, NC, USA
> 919-389-8678
>
> dboth at millennium-technology.com
>
> www.millennium-technology.com
> www.databook.bz - Home of the DataBook for Linux
> DataBook is a Registered Trademark of David Both
> *********************************************************
> This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately.
>


More information about the TriLUG mailing list