linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
* [linux-lvm] Sparse LVs, --virtualsize equal to --size
@ 2013-01-24 15:53 Vangelis Koukis
  2013-01-24 18:08 ` Alasdair G Kergon
  0 siblings, 1 reply; 12+ messages in thread
From: Vangelis Koukis @ 2013-01-24 15:53 UTC (permalink / raw)
  To: linux-lvm; +Cc: synnefo-devel

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

Hello,

I have been experimenting with LVM's sparse LVs feature.
If I understand correctly, a sparse device of --virtualsize
of V GBs and --size of S GBs is implemented as a snapshot over
two devices:

a) a virtual device of V GBs returning all zero blocks, and
b) a COW device of length S GBs.

Reads from the sparse LV return all zeroes, writes allocate
a new exception and store the newly written data inside the COW device.

If the COW device runs out of space, the snapshot is in trouble:
[11285507.534891] device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception.

For my use case, I don't care about the potential space savings
of having S << V and still see a huge device of size V GB.
I'd like to have S == V, since I only care about having a virtual device
that returns all zeroes for yet-unwritten blocks.

Setting S == V causes the snapshot to die miserably when the virtual
device is fully overwritten, because it seems the COW device runs out of
space. The manpage for lvcreate(8) does state that:

"Note that a small amount of the space you allocate to the snapshot is used to
track the locations of the chunks of data, so you should allocate slightly more
space than you actually need and monitor the rate@which the snapshot data
is growing so you can avoid running out of space."

So, what I'd like to know is:
a) What is the relation between S, V and the snapshot chunk size?
How much is "slightly more", how larger should S be compared to V, to ensure
the COW device *never* runs out of space?

b) How are blocks allocated inside the COW device when establishing mappings?
My guess is they are allocated sequentially, but in my case, when S == V, I
don't really need a full mapping. All LVM has to do, is remember whether a
chunk has already been written or not, it doesn't need to translate the chunk
number.
Not having to do any translation of chunk numbers from snapshot to COW would be
great, because the I/O patterns on the COW device would follow the I/O patterns
of the sparse device.
Is there any way I can do that, only exploit the tracking of writes, without
messing up the ordering of chunks between the virtual and COW devices?

Thank you,
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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2013-02-06 16:05 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-24 15:53 [linux-lvm] Sparse LVs, --virtualsize equal to --size Vangelis Koukis
2013-01-24 18:08 ` Alasdair G Kergon
2013-01-24 18:35   ` Stuart D Gathman
2013-01-24 23:42     ` Alasdair G Kergon
2013-01-25  8:44       ` Vangelis Koukis
2013-01-25 12:29         ` Alasdair G Kergon
2013-01-25 16:19           ` Vangelis Koukis
2013-01-28 13:50         ` Marian Csontos
2013-01-29  8:24           ` Vangelis Koukis
2013-01-31 16:22             ` Lars Ellenberg
2013-02-06 16:05               ` Vangelis Koukis
2013-01-25  8:39     ` Vangelis Koukis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).