linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Testing the new LVM cache feature
Date: Thu, 22 May 2014 16:43:49 +0200	[thread overview]
Message-ID: <537E0D25.7010108@redhat.com> (raw)
In-Reply-To: <20140522101837.GB14236@redhat.com>

Dne 22.5.2014 12:18, Richard W.M. Jones napsal(a):
>
> I've set up a computer in order to test the new LVM cache feature.  It
> has a pair of 2 TB HDDs in RAID 1 configuration, and a 256 GB SSD.
> The setup will be used to store large VM disk images in an ext4
> filesystem, to be served both locally and over NFS.
>
> Before I start I have some questions about this feature:
>
> (1) Is there a minimum recommended version of LVM or kernel to use?  I
> currently have lvm2-2.02.106-1.fc20.x86_64, which mentions LVM cache
> in the lvm(8) man page.  I have kernel 3.14.3-200.fc20.x86_64.

With these new targets usually always applies - the newer the kernel and tools 
are - the better for you.

>
> (2) There is no lvmcache(7) man page in any released version of LVM2.
> Was this man page ever created or is lvm(8) the definitive
> documentation?

It's now in upstream git as a separate man page (moved from lvm(8))

> (3) It looks as if cached LVs cannot be resized:
> https://www.redhat.com/archives/lvm-devel/2014-February/msg00119.html
> Will this be fixed in future?  Is there any workaround -- perhaps

Yes - cache is still missing a lot of feature - it needs further
integration with tools like  cache_check, cache_repair....

So far it's really only for a preview - I'd not consider to use it
for anything serious yet.

> removing the caching layer, resizing the original LV, then recreating
> the cache?  I really need to be able to resize LVs :-)

Surely this feature will be implemented.
Meanwhile - you have to drop cache, resize LV, reattach cache...
(drop cache - means to remove cache)

> (4) To calculate the size of the cache metadata LV, do I really just
> divide by 1000, min 8 MB?  It's that simple?  Doesn't it depend on
> dm-cache block size?  Or dm-cache algorithm?  How can I choose block
> size and algorithm?

Well this is where your experimenting may begin.
However for now  lvm2 doesn't allow you to play with algorithms - the lvchange 
interface is not yet upstream...

> (5) Is there an explicit command for flushing the cache layer back to
> the origin LV?

To be developed...

> (6) Is the on-disk format stable for future kernel/LVM upgrades?

Well it's still experiemental - so if there will be found some huge problem,
which requires to change/modify format it may happen.

Zdenek

  reply	other threads:[~2014-05-22 14:43 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22 10:18 [linux-lvm] Testing the new LVM cache feature Richard W.M. Jones
2014-05-22 14:43 ` Zdenek Kabelac [this message]
2014-05-22 15:22   ` Richard W.M. Jones
2014-05-22 15:49     ` Richard W.M. Jones
2014-05-22 18:04       ` Mike Snitzer
2014-05-22 18:13         ` Richard W.M. Jones
2014-05-29 13:52           ` Richard W.M. Jones
2014-05-29 20:34             ` Mike Snitzer
2014-05-29 20:47               ` Richard W.M. Jones
2014-05-29 21:06                 ` Mike Snitzer
2014-05-29 21:19                   ` Richard W.M. Jones
2014-05-29 21:58                     ` Mike Snitzer
2014-05-30  9:04                       ` Richard W.M. Jones
2014-05-30 10:30                         ` Richard W.M. Jones
2014-05-30 13:38                         ` Mike Snitzer
2014-05-30 13:40                           ` Richard W.M. Jones
2014-05-30 13:42                           ` Heinz Mauelshagen
2014-05-30 13:54                             ` Richard W.M. Jones
2014-05-30 13:58                               ` Zdenek Kabelac
2014-05-30 13:46                           ` Richard W.M. Jones
2014-05-30 13:54                             ` Heinz Mauelshagen
2014-05-30 14:26                               ` Richard W.M. Jones
2014-05-30 14:29                                 ` Mike Snitzer
2014-05-30 14:36                                   ` Richard W.M. Jones
2014-05-30 14:44                                     ` Mike Snitzer
2014-05-30 14:51                                       ` Richard W.M. Jones
2014-05-30 14:58                                         ` Mike Snitzer
2014-05-30 15:28                                           ` Richard W.M. Jones
2014-05-30 18:16                                             ` Mike Snitzer
2014-05-30 20:53                                               ` Mike Snitzer
2014-05-30 13:55                             ` Mike Snitzer
2014-05-30 14:29                               ` Richard W.M. Jones
2014-05-30 14:36                                 ` Mike Snitzer
2014-05-30 11:53                       ` Mike Snitzer
2014-05-30 11:38                 ` Alasdair G Kergon
2014-05-30 11:45                   ` Alasdair G Kergon
2014-05-30 12:45                     ` Werner Gold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=537E0D25.7010108@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).