* [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
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 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 0 siblings, 1 reply; 12+ messages in thread From: Alasdair G Kergon @ 2013-01-24 18:08 UTC (permalink / raw) To: Vangelis Koukis; +Cc: synnefo-devel, linux-lvm If you've got the capacity to test, create one that's quite a bit larger and see how much space it actually uses up when full, then use that size in future. There's a header, and then the blocks are written sequentially with an index block inserted ahead of each group of data blocks. Or try out thin LVs available in recent LVM releases/kernels for an alternative 'sparse' approach. Alasdair ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 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:39 ` Vangelis Koukis 0 siblings, 2 replies; 12+ messages in thread From: Stuart D Gathman @ 2013-01-24 18:35 UTC (permalink / raw) To: linux-lvm Long ago, Nostradamus foresaw that on 01/24/2013 01:08 PM, Alasdair G Kergon would write: > If you've got the capacity to test, create one that's quite a bit > larger and see how much space it actually uses up when full, then use > that size in future. There's a header, and then the blocks are written > sequentially with an index block inserted ahead of each group of > data blocks. > > Or try out thin LVs available in recent LVM releases/kernels for > an alternative 'sparse' approach. He doesn't actually want sparse, he wants "instant zero" via copy on write. This is useful for virtual machines by preventing information leaks between customers. Currently, you can create a "template" LV, and have a snapshot for each VM. Since you (almost) never write to the template, you don't run into the performance issue. He proposed a new type of LV that is a normal LV plus a small bitmap (1 bit per chunk) that tracks which chunks have been written to. When a chunk is written to, the remainder of that chunk is set to zero. Reads from unwritten chunks always return zeroes. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 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 8:39 ` Vangelis Koukis 1 sibling, 1 reply; 12+ messages in thread From: Alasdair G Kergon @ 2013-01-24 23:42 UTC (permalink / raw) To: LVM general discussion and development 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 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-28 13:50 ` Marian Csontos 0 siblings, 2 replies; 12+ messages in thread From: Vangelis Koukis @ 2013-01-25 8:44 UTC (permalink / raw) To: LVM general discussion and development; +Cc: synnefo-devel [-- Attachment #1: Type: text/plain, Size: 947 bytes --] 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? 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 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 1 sibling, 1 reply; 12+ messages in thread From: Alasdair G Kergon @ 2013-01-25 12:29 UTC (permalink / raw) To: Vangelis Koukis; +Cc: synnefo-devel, LVM general discussion and development On Fri, Jan 25, 2013 at 10:44:10AM +0200, Vangelis Koukis wrote: > this seems to fit the bill perfectly, it's a shame it's > not yet merged upstream. One of the reasons the zeroed target is not upstream is because, although we thought it would be useful, we had nobody actually asking to test and use it. If we bring it up-to-date and prepare to merge it upstream, would you test it? Alasdair ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 2013-01-25 12:29 ` Alasdair G Kergon @ 2013-01-25 16:19 ` Vangelis Koukis 0 siblings, 0 replies; 12+ messages in thread From: Vangelis Koukis @ 2013-01-25 16:19 UTC (permalink / raw) To: linux-lvm; +Cc: synnefo-devel [-- Attachment #1: Type: text/plain, Size: 1564 bytes --] On Fri, Jan 25, 2013 at 12:29:22pm +0000, Alasdair G Kergon wrote: > On Fri, Jan 25, 2013 at 10:44:10AM +0200, Vangelis Koukis wrote: > > this seems to fit the bill perfectly, it's a shame it's > > not yet merged upstream. > > One of the reasons the zeroed target is not upstream is because, > although we thought it would be useful, we had nobody actually > asking to test and use it. > > If we bring it up-to-date and prepare to merge it upstream, would you > test it? > > Alasdair Dear Alasdair, this functionality is really useful, especially in VM provisioning scenarios. The need for this feature came through our work on the Synnefo cloud software [1]. We were already planning to contribute code to Ganeti [2], so it can allocate sparse LVs based on the snapshot feature. If the zeroed DM target makes it upstream, we'll implement support for it inside Ganeti and also propose it for inclusion upstream. Then I won't just be able to test it manually, we'll be running Ganeti burnin against it, and the number of potential testers will include users currently running Ganeti and Synnefo in production. Thanks, Vangelis. [1] http://www.synnefo.org [2] http://code.google.com/p/ganeti -- 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
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 2013-01-25 8:44 ` Vangelis Koukis 2013-01-25 12:29 ` Alasdair G Kergon @ 2013-01-28 13:50 ` Marian Csontos 2013-01-29 8:24 ` Vangelis Koukis 1 sibling, 1 reply; 12+ messages in thread From: Marian Csontos @ 2013-01-28 13:50 UTC (permalink / raw) To: LVM general discussion and development; +Cc: synnefo-devel, Vangelis Koukis 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? 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... 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. -- Marian > > Thanks again, > Vangelis. > > > > > _______________________________________________ > 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 2013-01-28 13:50 ` Marian Csontos @ 2013-01-29 8:24 ` Vangelis Koukis 2013-01-31 16:22 ` Lars Ellenberg 0 siblings, 1 reply; 12+ messages in thread From: Vangelis Koukis @ 2013-01-29 8:24 UTC (permalink / raw) To: Marian Csontos; +Cc: synnefo-devel, LVM general discussion and development [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 2013-01-29 8:24 ` Vangelis Koukis @ 2013-01-31 16:22 ` Lars Ellenberg 2013-02-06 16:05 ` Vangelis Koukis 0 siblings, 1 reply; 12+ messages in thread From: Lars Ellenberg @ 2013-01-31 16:22 UTC (permalink / raw) To: linux-lvm On Tue, Jan 29, 2013 at 10:24:43AM +0200, Vangelis Koukis wrote: > 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) BTW, I've seen activation of "thin" snapshots take "ages" as well. Maybe not "few" hours, but close. That's because the implicitly started thin_check is 100% cpu on a single core, we have 64k "chunk size", and thus the tree is *huge*. Also lvremove of a thin snapshot in that setup is single core cpu bound, takes >= 20 minutes or so, locks out any other lvm command for that time. That's with LVM version: 2.02.95(2)-RHEL6 (2012-10-16) Library version: 1.02.74-RHEL6 (2012-10-16) Driver version: 4.22.6 [ "tech preview", so that may still improve ;-) ] Back on topic: > > 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? 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. 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. Hope that helps, -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 2013-01-31 16:22 ` Lars Ellenberg @ 2013-02-06 16:05 ` Vangelis Koukis 0 siblings, 0 replies; 12+ messages in thread From: Vangelis Koukis @ 2013-02-06 16:05 UTC (permalink / raw) To: Lars Ellenberg; +Cc: linux-lvm [-- Attachment #1: Type: text/plain, Size: 2975 bytes --] 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@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
* Re: [linux-lvm] Sparse LVs, --virtualsize equal to --size 2013-01-24 18:35 ` Stuart D Gathman 2013-01-24 23:42 ` Alasdair G Kergon @ 2013-01-25 8:39 ` Vangelis Koukis 1 sibling, 0 replies; 12+ messages in thread From: Vangelis Koukis @ 2013-01-25 8:39 UTC (permalink / raw) To: Stuart D Gathman; +Cc: synnefo-devel, linux-lvm [-- Attachment #1: Type: text/plain, Size: 2026 bytes --] On Thu, Jan 24, 2013 at 01:35:56pm -0500, Stuart D Gathman wrote: > Long ago, Nostradamus foresaw that on 01/24/2013 01:08 PM, Alasdair G > Kergon would write: > > If you've got the capacity to test, create one that's quite a bit > > larger and see how much space it actually uses up when full, then use > > that size in future. There's a header, and then the blocks are written > > sequentially with an index block inserted ahead of each group of > > data blocks. > > > > Or try out thin LVs available in recent LVM releases/kernels for > > an alternative 'sparse' approach. > He doesn't actually want sparse, he wants "instant zero" via copy on > write. This is useful for virtual machines by preventing information > leaks between customers. Currently, you can create a "template" LV, > and have a snapshot for each VM. Since you (almost) never write to the > template, you don't run into the performance issue. He proposed a new > type of LV that is a normal LV plus a small bitmap (1 bit per chunk) > that tracks which chunks have been written to. When a chunk is written > to, the remainder of that chunk is set to zero. Reads from unwritten > chunks always return zeroes. > Spot on! "Guaranteed initialized to zero" is what I'm looking for. So the LVM snapshot mechanism would work, but it may be a bit of an overkill. I'd rather not do it in a trial-and-error fashion, trying different values of S just a bit larger than V, until it works. How large is the overhead per chunk? Ideally, we could quantify the overhead as a fraction of the chunk size, and use it as a safe margin for estimating the needed physical size. 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 --] ^ 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).