From: Zdenek Kabelac <zkabelac@redhat.com>
To: lvm-devel@redhat.com
Subject: cache support
Date: Wed, 05 Feb 2014 10:35:06 +0100 [thread overview]
Message-ID: <52F205CA.1090807@redhat.com> (raw)
In-Reply-To: <096101cf2214$d241ed60$76c5c820$@acm.org>
Dne 5.2.2014 02:51, Paul B. Henson napsal(a):
> So I was browsing through the last month or so of list archives and
> reviewing the cache support under development, and had a question regarding
> use cases. Unless I am misunderstanding, it looks like the support being
> built so far addresses the use case of taking two lv's (a large slow origin
> lv and a small fast cache lv) and combining them into a third lv.
>
> Is there any intention to support a use case where you can attach a cache to
> the underlying pv, and have every single lv created on that pv cached? On a
> virtualization server I'm working on, I have an md raid1 of two 256G SSD's,
> and an md raid10 of four 2TB hard drives. What I'd like to do is create a
> cache device consisting of those two raid devices, and create a pv/vg on top
> of that. I know that is possible with the raw underlying dm-cache
> implementation, but it didn't look like the initial code dropped in lvm so
> far would support something like that?
Well - there is work in progress in upstream git - but it's highly
'experimental' and its user-space API can change any minute - so it's only
useful for playing - but not for any real use yet.
The device stacking is getting quite complex.
Side note - lvm2 now supports it's own metadata format for md raid1 - this
should allow better handling of device stack (it's using same kernel driver as
mdraid) - use just a single command to active everything in proper order.
Current version of dm-cache supports only 1:1 mapping - so one large cache
shared by multiple LVs is not supported. You will need to prepare smaller
individual cache pools for each of your LV.
lvm2 side is designed to allow to play with more different cache targets in
future.
Zdenek
next prev parent reply other threads:[~2014-02-05 9:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-05 1:51 cache support Paul B. Henson
2014-02-05 7:35 ` Oliver Rath
2014-02-05 20:12 ` Paul B. Henson
2014-02-05 9:35 ` Zdenek Kabelac [this message]
2014-02-05 20:20 ` Paul B. Henson
2014-02-05 21:29 ` Zdenek Kabelac
2014-02-06 1:36 ` Paul B. Henson
2014-02-11 17:24 ` Brassow Jonathan
2014-02-11 21:04 ` Paul B. Henson
2014-02-12 17:39 ` Brassow Jonathan
2014-02-17 22:12 ` Paul B. Henson
2014-03-11 23:54 ` Paul B. Henson
2014-03-17 15:56 ` Brassow Jonathan
2014-03-18 1:07 ` Paul B. Henson
2014-03-29 1:38 ` Paul B. Henson
2014-03-29 1:43 ` Paul B. Henson
2014-04-02 20:34 ` Brassow Jonathan
2014-04-03 2:54 ` Paul B. Henson
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=52F205CA.1090807@redhat.com \
--to=zkabelac@redhat.com \
--cc=lvm-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.