[linux-lvm] Sparse LVs, --virtualsize equal to --size

[Vangelis Koukis]

On Thu, Jan 31, 2013 at 05:22:43pm +0100, Lars Ellenberg wrote:
> > What is old-style snapshots? Old-style compared to what, thin LVs?
> 
> Yes.
> 
> > By "activate", do you refer to the problem of very slow VG activation
> 
> Yes.
> 
> > 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".
> byte number
> 1                     [old][new]
> 2                     [old][new]
> 3                     ...
> (chunk_size*512/16)   [old][new]
> following are as many data chunks.
> 
> this whole thing is append only.
> 

Dear Lars,

Thank you very much for the detailed explanation!
This is exactly what I needed, thanks for your time to gather everything
into a single answer.

> On activation,
> 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.
> 
> 

Yes, so there is no fixed index or bitmap on disk to determine whether a
block is in an exception list or not. LVM has to scan all blocks, and
build this structure in main memory, on activation time.

This makes old-style snapshots completely unsuitable for our use case.
I guess dm-zeroed is what we should go for, from the available options.

> Hope that helps,
> 

It was great help.

Thanks again,
Vangelis.

-- 
Vangelis Koukis
vkoukis at grnet.gr
OpenPGP public key ID:
pub  1024D/1D038E97 2003-07-13 Vangelis Koukis <vkoukis at cslab.ece.ntua.gr>
     Key fingerprint = C5CD E02E 2C78 7C10 8A00  53D8 FBFC 3799 1D03 8E97

Only those who will risk going too far
can possibly find out how far one can go.
        -- T.S. Eliot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20130206/e284807b/attachment.sig>