All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John Stoffel" <john@stoffel.org>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: [RFC] zodcache - auto-start dm-cache devices
Date: Fri, 18 Dec 2015 11:07:20 -0500	[thread overview]
Message-ID: <22132.12088.729694.12882@quad.stoffel.home> (raw)
In-Reply-To: <n508c1$8dl$1@ger.gmane.org>


Ian> I've been looking for a "simple" way to manage dm-cache devices
Ian> for a while now -- something that operates a bit more like bcache
Ian> than LVM cache does, while still using the dm-cache
Ian> infrastructure.  Having not found anything, I finally created
Ian> "zodcache".  (The name is mostly due to wanting something that
Ian> could be used as a magic number -- 20DCAC8E.)

Ian> Hopefully the README does a decent job of explaining how it works, so I
Ian> won't belabor it here:

I just read this over because I've just deployed lvmcache on my home
system, and I was interested in how this would be different.  One
thing I would comment on is that having a diagram comparting the three
options would be really useful.

From my reading of the docs, it's clear that zodcache is lower down
the stack than LVMcache, but higher than bcache.

For my setup, I have a pair of mirrored SSDs for root, /boot and
lvmcache partitions.  I'm using MD to mirror the partitions I've
created on the SSDs.

I then have another MD mirror composed of two 4Tb disks, which is
turned into a PV in a VG with a bunch of LVs which are now cached.
Before I had seperate VGs for some of my data, but now I've coalesced
them so that I don't need multiple MD arrays for seperate cache PVs in
each VG.

So describinng how your setup can provide a central cache pool across
multiple VGs would be awesome, but it's not quite clear to me that you
can do this in reality without doing multiple layers of block devices.

And since I'm paranoid (to a degree!) about resiliency, mirroring the
cache devices is a critical part for me.

Also, I'm on debian, so that's another piece of documentation that's
kinda sorta missing.

John

  parent reply	other threads:[~2015-12-18 16:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-18  6:16 [RFC] zodcache - auto-start dm-cache devices Ian Pilcher
2015-12-18  9:44 ` Joe Thornber
2015-12-18 16:07 ` John Stoffel [this message]
2015-12-18 16:55   ` Ian Pilcher
2015-12-18 17:39     ` Ian Pilcher
2015-12-18 18:53     ` John Stoffel
2015-12-18 18:51 ` Alasdair G Kergon
2015-12-18 19:44   ` John Stoffel
2015-12-18 20:01     ` Alasdair G Kergon
2015-12-18 20:50   ` Ian Pilcher
2015-12-18 21:06     ` Zdenek Kabelac
2015-12-19  0:01       ` Ian Pilcher
2015-12-19  0:53 ` Never mind (was [RFC] zodcache - auto-start dm-cache devices) Ian Pilcher
2015-12-19  1:53   ` John Stoffel
2016-01-04 15:52     ` Joe Thornber
2016-01-06 15:49       ` Ian Pilcher

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=22132.12088.729694.12882@quad.stoffel.home \
    --to=john@stoffel.org \
    --cc=dm-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.