Re: [linux-lvm] thinpool metadata size

[Mike Snitzer <snitzer@redhat.com>]

On Wed, Mar 12 2014 at  9:32pm -0400,
Paul B. Henson <henson@acm.org> wrote:

> > From: Mike Snitzer
> > Sent: Wednesday, March 12, 2014 4:35 PM
> >
> > No, metadata resize is now available.
> 
> Oh, cool; that makes the initial allocation decision a little less critical
> :).
> 
> > But you definitely want to be
> > using the latest kernel (there have been various fixes for this
> > feature).
> 
> I thought I saw a thin pool metadata corruption issue fly by recently with a
> fix destined for 3.14, I was tentatively thinking of waiting for the 3.14
> release before migrating my box to thin provisioning. I'm currently running
> 3.12, it looks like that was designated a long-term support kernel? Are thin
> provisioning (and dm-cache, as I'm going to add that to the mix as soon as
> lvm supports it) patches going to be backported to that, or would it be
> better to track mainline stable kernels as they are released?

The important fixes for long-standing issues will be marked for stable,
e.g.: http://git.kernel.org/linus/cebc2de44d3bce53 (and yes I already
sent a note to stable@ to have them pull this in to 3.12-stable too)

But significant improvements will not be.  The biggest recent example of
this are all the improvements made in 3.14 for "out-of-data-space" mode
and all the associated error handling improvements.

So if I were relegated to using upstream kernels, I'd track latest
stable kernel if I could.  Otherwise, I'd do my own backports -- but
wouldn't expect others to support my backports.

> > Completely exhausting all space in the metadata device will expose you
> > to a corner case that still needs work... so best to avoid that by
> > sizing your metadata device conservatively (larger).
> 
> On the grand scale of things it doesn't look like it wants that much space,
> so over allocation sounds like a good idea.
> 
> > The largest the metadata volume can be is just under 16GB.  The size of
> > the metadata device will depend on the blocksize and number of expected
> > snapshots.
> 
> Interesting; for some reason I thought metadata usage was also dependent on
> changes between origin and snapshots. So, if you had one origin lv and 100
> snapshots of it that were all identical, it would use less metadata than if
> you had 100 snapshots that had been written to and were all wildly divergent
> from each other. Evidently not though?

I'm not sure if the tool tracks the rate of change.  It may account for
worst case of _every_ block for the provided number of thin devices
_not_ being shared.