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 at 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:
signature.asc
Description: Digital signature
_______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
