[dm-devel] dm-cache questions

[Paul B. Henson]

> From: Joe Thornber
> Sent: Tuesday, December 10, 2013 1:50 AM
>
> I've just found a serious bug that causes metadata space to be used up
> too quickly.  So hold off until I get a patch together later this week.

Ouch. Life on the bleeding edge ;). Do fixes like this get backported to
3.10LTS, or just to the latest mainline/stable kernel? One nice thing about
dm-cache is that it layers transparently on top of your origin device, so it
can be dropped in at any time. I've been kind of stalled moving forward
waiting to sort out caching, but I think I can go ahead and get everything
set up and then just drop dm-cache in on top of it later. I guess the other
side of that coin is you have to be careful to make sure nothing accesses
the origin device directly rather than through the cache once it's set up,
as that would be a sure recipe for corruption...

> The metadata is stored in btrees, damaging a high level node in this
> btree can lose an awful lot of mappings.  So I recommend mirroring it.

If the metadata device is an SSD, does there end up being a lot of write
amplifications due to the small updates being made to the metadata?

> spindle.  Your volume manage (eg, LVM2) should be doing this
> transparently for you.

Any idea when dm-cache support is going to show up in lvm2? Reviewing the
last few months of mailing list traffic on that list, I don't see any
mention of it. I found a message dating back to March 2013 that said "within
a few months", but perhaps that was optimistic :). Do you think lvm2 would
recognize and be able to manage a "handmade" dm-cache once it is released,
or would you need to clean out the cache, remove it, and then re-create it
with lvm2?

> Personally I'd use linear, since it allows you to resize easily.

After looking at it again, it is simpler than it appeared on first
impression.

> Use the normal suspend, reload, resume cycle.

Ah, ok, I thought suspend removed the device, but it just freezes I/O and
pauses applications until you bring it back.

> dm-cache both passes down trim messages, and keeps track of discarded
> origin blocks in it's metadata to avoid redundant io on
promotion/demotion.

So if your origin device supports trim, it will see them, but what about the
cache device, which is only being used by dm-cache? Does dm-cache
occasionally trim the cache device to free unused blocks?

> No problem, yell if you need more help.

Cool, thanks much.