[linux-lvm] Sparse LVs, --virtualsize equal to --size
lars.ellenberg at linbit.com
Thu Jan 31 16:22:43 UTC 2013
On Tue, Jan 29, 2013 at 10:24:43AM +0200, Vangelis Koukis wrote:
> On Mon, Jan 28, 2013 at 02:50:48pm +0100, Marian Csontos wrote:
> > On 01/25/2013 09:44 AM, Vangelis Koukis wrote:
> > >On Thu, Jan 24, 2013 at 11:42:35pm +0000, Alasdair G Kergon wrote:
> > >>So look at thin provisioning with its zeroing option.
> > >>External origin. (support currently being added to lvm)
> > >>
> > >>Or this not-yet-upstream target:
> > >>http://people.redhat.com/agk/patches/linux/editing/dm-add-zeroed-target.patch
> > >>
> > >>Alasdair
> > >
> > >Thanks Alasdair,
> > >
> > >this seems to fit the bill perfectly, it's a shame it's
> > >not yet merged upstream.
> > >
> > >Until then, if we are to go with the "snapshot-over-the-zero-target"
> > >route, can you comment on quantifying the space overhead of tracking
> > >chunks in the snapshot?
> Hello Marian,
> thank you for your answer, here are some points I'm not sure I have
> understood completely:
> > Beware! Large old-style snapshots may take a very long time to
> > activate (reportedly up to few hours)
I've seen activation of "thin" snapshots take "ages" as well.
Maybe not "few" hours, but close.
That's because the implicitly started thin_check is 100% cpu
on a single core, we have 64k "chunk size",
and thus the tree is *huge*.
Also lvremove of a thin snapshot in that setup is single core cpu bound,
takes >= 20 minutes or so, locks out any other lvm command for that time.
LVM version: 2.02.95(2)-RHEL6 (2012-10-16)
Library version: 1.02.74-RHEL6 (2012-10-16)
Driver version: 4.22.6
[ "tech preview", so that may still improve ;-) ]
Back on topic:
> > and my guess is many
> > smaller snapshots will behave the same, the total amount of
> > chunks written to all snapshots being the key to slow start...
> What is old-style snapshots? Old-style compared to what, thin LVs?
> By "activate", do you refer to the problem of very slow VG activation
> If yes, then the question still remains:
> Can you please comment on the exact on-disk format used when doing LVM
> snapshots? What is the exact format of the blocks being written to the
> COW volume?
I'm pasting parts of an older post to this list
(from 2008, Restore LVM snapshot without creating a full dump to an "external" device?)
"old style snapsthots", aka
dm-snap and dm-exception-store are implemented in a way that
for a single snapshot, you get
(mapping only) snapshot-origin
(real storage) origin-real
(mapping only) snapshot
(real storage) COW (or exception store)
COW on disk format is pretty simple (as of now).
its all fixed size chunks.
it starts with a 4x32bit header,
[SnAp][valid][version][chunk_size in sectors]
so any valid snapshot looks
"SnAp" 1 1 [power of two]
chunk_size it what you set with the lvcreate "-c" option.
the rest of the (just as well chunk_size'ed) header block is unused.
expressed in chunks, the COW storage looks like:
[header chunk][exception area 0][data chunks][....][exception area 1][...]
where each exception area is one "chunk" itself.
each exception area holds a mapping table of
"logic chunk number" to "in COW storage chunk number", both 64bit.
"logic number" is called "old", "in COW" address is called "new".
following are as many data chunks.
this whole thing is append only.
it needs to scan all those [exception area ...] blocks,
until it find the "terminating" zeroed one.
It reads in and stores this mapping in core memory.
Hope that helps,
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
More information about the linux-lvm