linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Vangelis Koukis <vkoukis@grnet.gr>
To: linux-lvm@redhat.com
Cc: synnefo-devel@googlegroups.com
Subject: [linux-lvm] Sparse LVs, --virtualsize equal to --size
Date: Thu, 24 Jan 2013 17:53:12 +0200	[thread overview]
Message-ID: <20130124155312.GA10563@daedalus.cslab.ece.ntua.gr> (raw)

[-- 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 --]

             reply	other threads:[~2013-01-24 15:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24 15:53 Vangelis Koukis [this message]
2013-01-24 18:08 ` [linux-lvm] Sparse LVs, --virtualsize equal to --size 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130124155312.GA10563@daedalus.cslab.ece.ntua.gr \
    --to=vkoukis@grnet.gr \
    --cc=linux-lvm@redhat.com \
    --cc=synnefo-devel@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).