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

[Vangelis Koukis <vkoukis@grnet.gr>]

[-- Attachment #1: Type: text/plain, Size: 2967 bytes --]

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[1] (reportedly up to few hours) and my guess is many
> smaller snapshots will behave the same[2], 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
e.g., on boot, as described here?

http://unix.stackexchange.com/questions/20152/why-does-activation-of-lvm-partition-with-large-snapshot-takes-long-time
https://bugs.launchpad.net/lvm2/+bug/360237

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 think this would make clear both a) what the space overhead per
snapshot chunk is, b) why it takes so long to activate an LVM VG if the
snapshot has grown too large (i.e., if too much information has found
its way into the COW volume).

> You should definitely try it with your workflow before going too far
> that direction.
> 
> [1]Just search for 'lvm large snapshot'. Someone here may be able to
> point you to a more complete data.
> 
> [2] Not even trying to think about many larger ones as your usecase
> suggests: just update kernel and java few times and with journal FS
> you will soon be at few gigabytes per VM.
> 

I understand this may well be the case, but I'd like to know the
*reason* for the symptom you describe.

Could you point me to information on the exact way snapshots are
implemented, a design doc, a specification? Is the process specified
only by the code that implements it?

Thanks again,
Vangelis.

-- 
Vangelis Koukis
vkoukis@grnet.gr
OpenPGP public key ID:
pub  1024D/1D038E97 2003-07-13 Vangelis Koukis <vkoukis@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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]