From: Paul B. Henson <henson@acm.org>
To: lvm-devel@redhat.com
Subject: cache support
Date: Wed, 5 Feb 2014 12:20:11 -0800 [thread overview]
Message-ID: <0a3901cf22af$ae01d2d0$0a057870$@acm.org> (raw)
In-Reply-To: <52F205CA.1090807@redhat.com>
> From: Zdenek Kabelac
> Sent: Wednesday, February 05, 2014 1:35 AM
>
> 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.
Agreed :). I'm just looking to try and make sure that as it stabilizes my
desired use case fits in the picture ;).
> 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.
I've read somewhat about the integration of mdraid and lvm, but not enough
to fully understand it or be comfortable about switching from classic mdraid
to lvm integrated mdraid.
> 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.
I'm not sure what you mean here; I confirmed on the device mapper mailing
list that using dm-cache directly would support my desired stacking of
placing a PV on top of a dm-cache device that is sitting on top of a raw SSD
raid1 md cache device and a raw HD raid10 origin device, effectively using
the single cache device to cache all of the LV's created on the PV. I don't
really want to split up the cache device into bits and pieces for each
individual LV, that doesn't seem very efficient; I'd rather have the entire
cache device available for which ever LV's happen to be hot at a given time.
So it's really just a question of whether or not lvm is going to support a
user-friendly layer on top of dm-cache for this type of stacking, or if
somebody will be stuck using dm-cache directly if they want to implement
something like this.
Thanks.
next prev parent reply other threads:[~2014-02-05 20:20 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
2014-02-05 20:20 ` Paul B. Henson [this message]
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='0a3901cf22af$ae01d2d0$0a057870$@acm.org' \
--to=henson@acm.org \
--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.