You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Wido den Hollander <wi...@widodh.nl> on 2015/03/10 14:47:09 UTC
Overprovisioning of local storage
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I've ran into the issue where it seems that local storage can't be
overprovisioned.
storage.overprovisioning.factor is set to 1.5 in both the global and
zone settings, but this is ignored.
In this case it's a 1TB SSD which currently has 68GB allocated on
disk, but 750GB of disk space has been allocated according to CloudStack.
Looking StorageManagerImpl there is this if-statement:
if (storagePool.getPoolType() == StoragePoolType.NetworkFilesystem ||
storagePool.getPoolType() == StoragePoolType.VMFS) {
DO OVERPROVISION
} else {
DO NOT OVERPROVISION
}
So why is local storage excluded here? Since QCOW2 is sparsely
allocated and templates deployments are just clones of a parent QCOW2
it's fair to say that with local storage you can also overprovision?
Any objections to adding this?
Wido
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJU/vXdAAoJEAGbWC3bPspCSIEP/RW5Yzx5tap2YQxDMKjF5b/r
TewVIheKexlvOsr6BzVY4M++55YutZjXBGzRouy//d2T5ozqJg7EyrXZtzU3wbXM
T/nyMjyuvziGjB/poTHVDE+yEDQ79UbU2BXKdp5CYBZJHDSw1ilZajUqo26KhqKb
N2xatwcCAo2p0dMMze3QwYxkd3gtMwkREok3lvN153SIhi2pKQSoRMU0eA68q0wZ
30jprOBnjqzGcRkbkvM6/KN84OB3720BNVuc3JbJPdItG7UchbzIW8bJvHfhMViD
MXZObpD0aWSLbZZYSfgNH+bL1P2XXldOWeQ+HI5q+A7Sf8q0i9PlEpAR+gqROHGA
UtGk8MCi0OP7zjXciDOHrhGYfxQ+o0iIF0knt6fCXpma+KzRDxQo6Eo7D2rHGv2e
8xarZ4oamhAmytUxiL2i74cNS6d248P4fER0CUQ4tML/4jdXMRvALud2XYwK+e+C
HRnZ0/X2YPzQbhJeZne8cYkf3vz3emLbck0dcgvAQtDIlPekeNAhs6Ik5hxCP29G
Nsp8LILw69VPcSkDAHmLV6Gzd1jaIxtObM67CQLA0F3q/ehFwD29mncxe7kh1AhP
yuW8s+oUjyQxhaV/glMTj2odbV4MfLA8Hzw3/wGtj6vHYcMAvCrRGGUo7gO5RPgv
l1tt1vl1aPA0OR7BZEXF
=I9Y1
-----END PGP SIGNATURE-----
Re: Overprovisioning of local storage
Posted by Marcus <sh...@gmail.com>.
It's been brought up quite a few times, actually. I think the reason
it hasn't been fixed yet is that the "right" fix is to make the
storage driver decide if it can do overprovision in a given situation,
which is a bit more work than just slapping together a long 'if'
statement.
On Tue, Mar 10, 2015 at 6:54 AM, Wido den Hollander <wi...@widodh.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 03/10/2015 02:50 PM, Andrija Panic wrote:
>> Nice question - I would like this fixed if possible...?
>>
>
> I created a Jira issue for this:
> https://issues.apache.org/jira/browse/CLOUDSTACK-8313
>
>> On 10 March 2015 at 14:47, Wido den Hollander <wi...@widodh.nl>
>> wrote:
>>
>> Hi,
>>
>> I've ran into the issue where it seems that local storage can't be
>> overprovisioned.
>>
>> storage.overprovisioning.factor is set to 1.5 in both the global
>> and zone settings, but this is ignored.
>>
>> In this case it's a 1TB SSD which currently has 68GB allocated on
>> disk, but 750GB of disk space has been allocated according to
>> CloudStack.
>>
>> Looking StorageManagerImpl there is this if-statement:
>>
>> if (storagePool.getPoolType() == StoragePoolType.NetworkFilesystem
>> || storagePool.getPoolType() == StoragePoolType.VMFS) { DO
>> OVERPROVISION } else { DO NOT OVERPROVISION }
>>
>> So why is local storage excluded here? Since QCOW2 is sparsely
>> allocated and templates deployments are just clones of a parent
>> QCOW2 it's fair to say that with local storage you can also
>> overprovision?
>>
>> Any objections to adding this?
>>
>> Wido
>>>
>>
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJU/veAAAoJEAGbWC3bPspCUFoQAI8OVRVziU0VE/nrRqmeOXLx
> FaBHxzO5L6sPfrFXz+qPjmZJmkMKoMWUgKmnp7DUCTBKqLINhhS07dMRRGZEY+tw
> 1yYYFIuvu6aak5M/LXhRIc0dns5KvLGMiGFkVJpJmO6jyLl8sqdPukpcV96wVm4C
> eXGgOSQUJ6ut/7W2j3hXu6+da9pZA0Wpm/8dFQw9YG+NjMo1cO1gq0d2XR3rkWJG
> r7JOsFMk8OWt0+HWA7RpUhMaKkhFDw3UDwTx5ejAoIgJAQ7RVJJrUZfojtn3TQa4
> nV3128TZGO1gO4jPrqgPneTGsn2d2rKBhIclglFX3VsTVx7snHJwnf+Ig3mwyOpT
> 1ebCqLsVBD0aNxh0J+9OHrfwnyMlOCPJADx/Q8VG/UxbEiYH4XB30E7WV4nsbndU
> 2OlAgfaUuFb8lbceknu67rcUVxblCsvBJYQKUArNJPavV/xV7I/kwxM++bizj+6V
> nk/ifHkztHEFpvDYkXEOwhrhUiZXTDJTFmCZ+hqdMgIbpGoNd+P6zw7gPU/IKsNI
> m5sdfmd2l2YeNIDbQYKt1v8uaaGWff9ql21FNfLfAqp5T6ayMf87Oev0JKsXvSqe
> rbh8wK+rdBU9dFscXixgKJ+se8OXdljSyH9KTsx+JIZxv4/X1kE2VnH/1U6JJlIW
> YYFmd6m6IsXV3YBtoU9n
> =NqzG
> -----END PGP SIGNATURE-----
Re: Overprovisioning of local storage
Posted by Wido den Hollander <wi...@widodh.nl>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/10/2015 02:50 PM, Andrija Panic wrote:
> Nice question - I would like this fixed if possible...?
>
I created a Jira issue for this:
https://issues.apache.org/jira/browse/CLOUDSTACK-8313
> On 10 March 2015 at 14:47, Wido den Hollander <wi...@widodh.nl>
> wrote:
>
> Hi,
>
> I've ran into the issue where it seems that local storage can't be
> overprovisioned.
>
> storage.overprovisioning.factor is set to 1.5 in both the global
> and zone settings, but this is ignored.
>
> In this case it's a 1TB SSD which currently has 68GB allocated on
> disk, but 750GB of disk space has been allocated according to
> CloudStack.
>
> Looking StorageManagerImpl there is this if-statement:
>
> if (storagePool.getPoolType() == StoragePoolType.NetworkFilesystem
> || storagePool.getPoolType() == StoragePoolType.VMFS) { DO
> OVERPROVISION } else { DO NOT OVERPROVISION }
>
> So why is local storage excluded here? Since QCOW2 is sparsely
> allocated and templates deployments are just clones of a parent
> QCOW2 it's fair to say that with local storage you can also
> overprovision?
>
> Any objections to adding this?
>
> Wido
>>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJU/veAAAoJEAGbWC3bPspCUFoQAI8OVRVziU0VE/nrRqmeOXLx
FaBHxzO5L6sPfrFXz+qPjmZJmkMKoMWUgKmnp7DUCTBKqLINhhS07dMRRGZEY+tw
1yYYFIuvu6aak5M/LXhRIc0dns5KvLGMiGFkVJpJmO6jyLl8sqdPukpcV96wVm4C
eXGgOSQUJ6ut/7W2j3hXu6+da9pZA0Wpm/8dFQw9YG+NjMo1cO1gq0d2XR3rkWJG
r7JOsFMk8OWt0+HWA7RpUhMaKkhFDw3UDwTx5ejAoIgJAQ7RVJJrUZfojtn3TQa4
nV3128TZGO1gO4jPrqgPneTGsn2d2rKBhIclglFX3VsTVx7snHJwnf+Ig3mwyOpT
1ebCqLsVBD0aNxh0J+9OHrfwnyMlOCPJADx/Q8VG/UxbEiYH4XB30E7WV4nsbndU
2OlAgfaUuFb8lbceknu67rcUVxblCsvBJYQKUArNJPavV/xV7I/kwxM++bizj+6V
nk/ifHkztHEFpvDYkXEOwhrhUiZXTDJTFmCZ+hqdMgIbpGoNd+P6zw7gPU/IKsNI
m5sdfmd2l2YeNIDbQYKt1v8uaaGWff9ql21FNfLfAqp5T6ayMf87Oev0JKsXvSqe
rbh8wK+rdBU9dFscXixgKJ+se8OXdljSyH9KTsx+JIZxv4/X1kE2VnH/1U6JJlIW
YYFmd6m6IsXV3YBtoU9n
=NqzG
-----END PGP SIGNATURE-----
Re: Overprovisioning of local storage
Posted by Andrija Panic <an...@gmail.com>.
Nice question - I would like this fixed if possible...?
On 10 March 2015 at 14:47, Wido den Hollander <wi...@widodh.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I've ran into the issue where it seems that local storage can't be
> overprovisioned.
>
> storage.overprovisioning.factor is set to 1.5 in both the global and
> zone settings, but this is ignored.
>
> In this case it's a 1TB SSD which currently has 68GB allocated on
> disk, but 750GB of disk space has been allocated according to CloudStack.
>
> Looking StorageManagerImpl there is this if-statement:
>
> if (storagePool.getPoolType() == StoragePoolType.NetworkFilesystem ||
> storagePool.getPoolType() == StoragePoolType.VMFS) {
> DO OVERPROVISION
> } else {
> DO NOT OVERPROVISION
> }
>
> So why is local storage excluded here? Since QCOW2 is sparsely
> allocated and templates deployments are just clones of a parent QCOW2
> it's fair to say that with local storage you can also overprovision?
>
> Any objections to adding this?
>
> Wido
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJU/vXdAAoJEAGbWC3bPspCSIEP/RW5Yzx5tap2YQxDMKjF5b/r
> TewVIheKexlvOsr6BzVY4M++55YutZjXBGzRouy//d2T5ozqJg7EyrXZtzU3wbXM
> T/nyMjyuvziGjB/poTHVDE+yEDQ79UbU2BXKdp5CYBZJHDSw1ilZajUqo26KhqKb
> N2xatwcCAo2p0dMMze3QwYxkd3gtMwkREok3lvN153SIhi2pKQSoRMU0eA68q0wZ
> 30jprOBnjqzGcRkbkvM6/KN84OB3720BNVuc3JbJPdItG7UchbzIW8bJvHfhMViD
> MXZObpD0aWSLbZZYSfgNH+bL1P2XXldOWeQ+HI5q+A7Sf8q0i9PlEpAR+gqROHGA
> UtGk8MCi0OP7zjXciDOHrhGYfxQ+o0iIF0knt6fCXpma+KzRDxQo6Eo7D2rHGv2e
> 8xarZ4oamhAmytUxiL2i74cNS6d248P4fER0CUQ4tML/4jdXMRvALud2XYwK+e+C
> HRnZ0/X2YPzQbhJeZne8cYkf3vz3emLbck0dcgvAQtDIlPekeNAhs6Ik5hxCP29G
> Nsp8LILw69VPcSkDAHmLV6Gzd1jaIxtObM67CQLA0F3q/ehFwD29mncxe7kh1AhP
> yuW8s+oUjyQxhaV/glMTj2odbV4MfLA8Hzw3/wGtj6vHYcMAvCrRGGUo7gO5RPgv
> l1tt1vl1aPA0OR7BZEXF
> =I9Y1
> -----END PGP SIGNATURE-----
>
--
Andrija Panić
Re: Overprovisioning of local storage
Posted by ilya musayev <il...@gmail.com>.
sorry, wrong solution.. but still relevant issue you may encounter
On 3/10/15 11:59 PM, ilya musayev wrote:
> fixed in 4.4, but i'd go with 4.5
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-7752
>
>
>
> On 3/10/15 6:47 AM, Wido den Hollander wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> I've ran into the issue where it seems that local storage can't be
>> overprovisioned.
>>
>> storage.overprovisioning.factor is set to 1.5 in both the global and
>> zone settings, but this is ignored.
>>
>> In this case it's a 1TB SSD which currently has 68GB allocated on
>> disk, but 750GB of disk space has been allocated according to
>> CloudStack.
>>
>> Looking StorageManagerImpl there is this if-statement:
>>
>> if (storagePool.getPoolType() == StoragePoolType.NetworkFilesystem ||
>> storagePool.getPoolType() == StoragePoolType.VMFS) {
>> DO OVERPROVISION
>> } else {
>> DO NOT OVERPROVISION
>> }
>>
>> So why is local storage excluded here? Since QCOW2 is sparsely
>> allocated and templates deployments are just clones of a parent QCOW2
>> it's fair to say that with local storage you can also overprovision?
>>
>> Any objections to adding this?
>>
>> Wido
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJU/vXdAAoJEAGbWC3bPspCSIEP/RW5Yzx5tap2YQxDMKjF5b/r
>> TewVIheKexlvOsr6BzVY4M++55YutZjXBGzRouy//d2T5ozqJg7EyrXZtzU3wbXM
>> T/nyMjyuvziGjB/poTHVDE+yEDQ79UbU2BXKdp5CYBZJHDSw1ilZajUqo26KhqKb
>> N2xatwcCAo2p0dMMze3QwYxkd3gtMwkREok3lvN153SIhi2pKQSoRMU0eA68q0wZ
>> 30jprOBnjqzGcRkbkvM6/KN84OB3720BNVuc3JbJPdItG7UchbzIW8bJvHfhMViD
>> MXZObpD0aWSLbZZYSfgNH+bL1P2XXldOWeQ+HI5q+A7Sf8q0i9PlEpAR+gqROHGA
>> UtGk8MCi0OP7zjXciDOHrhGYfxQ+o0iIF0knt6fCXpma+KzRDxQo6Eo7D2rHGv2e
>> 8xarZ4oamhAmytUxiL2i74cNS6d248P4fER0CUQ4tML/4jdXMRvALud2XYwK+e+C
>> HRnZ0/X2YPzQbhJeZne8cYkf3vz3emLbck0dcgvAQtDIlPekeNAhs6Ik5hxCP29G
>> Nsp8LILw69VPcSkDAHmLV6Gzd1jaIxtObM67CQLA0F3q/ehFwD29mncxe7kh1AhP
>> yuW8s+oUjyQxhaV/glMTj2odbV4MfLA8Hzw3/wGtj6vHYcMAvCrRGGUo7gO5RPgv
>> l1tt1vl1aPA0OR7BZEXF
>> =I9Y1
>> -----END PGP SIGNATURE-----
>
Re: Overprovisioning of local storage
Posted by ilya musayev <il...@gmail.com>.
fixed in 4.4, but i'd go with 4.5
https://issues.apache.org/jira/browse/CLOUDSTACK-7752
On 3/10/15 6:47 AM, Wido den Hollander wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I've ran into the issue where it seems that local storage can't be
> overprovisioned.
>
> storage.overprovisioning.factor is set to 1.5 in both the global and
> zone settings, but this is ignored.
>
> In this case it's a 1TB SSD which currently has 68GB allocated on
> disk, but 750GB of disk space has been allocated according to CloudStack.
>
> Looking StorageManagerImpl there is this if-statement:
>
> if (storagePool.getPoolType() == StoragePoolType.NetworkFilesystem ||
> storagePool.getPoolType() == StoragePoolType.VMFS) {
> DO OVERPROVISION
> } else {
> DO NOT OVERPROVISION
> }
>
> So why is local storage excluded here? Since QCOW2 is sparsely
> allocated and templates deployments are just clones of a parent QCOW2
> it's fair to say that with local storage you can also overprovision?
>
> Any objections to adding this?
>
> Wido
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJU/vXdAAoJEAGbWC3bPspCSIEP/RW5Yzx5tap2YQxDMKjF5b/r
> TewVIheKexlvOsr6BzVY4M++55YutZjXBGzRouy//d2T5ozqJg7EyrXZtzU3wbXM
> T/nyMjyuvziGjB/poTHVDE+yEDQ79UbU2BXKdp5CYBZJHDSw1ilZajUqo26KhqKb
> N2xatwcCAo2p0dMMze3QwYxkd3gtMwkREok3lvN153SIhi2pKQSoRMU0eA68q0wZ
> 30jprOBnjqzGcRkbkvM6/KN84OB3720BNVuc3JbJPdItG7UchbzIW8bJvHfhMViD
> MXZObpD0aWSLbZZYSfgNH+bL1P2XXldOWeQ+HI5q+A7Sf8q0i9PlEpAR+gqROHGA
> UtGk8MCi0OP7zjXciDOHrhGYfxQ+o0iIF0knt6fCXpma+KzRDxQo6Eo7D2rHGv2e
> 8xarZ4oamhAmytUxiL2i74cNS6d248P4fER0CUQ4tML/4jdXMRvALud2XYwK+e+C
> HRnZ0/X2YPzQbhJeZne8cYkf3vz3emLbck0dcgvAQtDIlPekeNAhs6Ik5hxCP29G
> Nsp8LILw69VPcSkDAHmLV6Gzd1jaIxtObM67CQLA0F3q/ehFwD29mncxe7kh1AhP
> yuW8s+oUjyQxhaV/glMTj2odbV4MfLA8Hzw3/wGtj6vHYcMAvCrRGGUo7gO5RPgv
> l1tt1vl1aPA0OR7BZEXF
> =I9Y1
> -----END PGP SIGNATURE-----