Open Stack

Roger,

Point 3 and 4 are totally different and the words are not the reason for
technical change. If you require technically accurate statistics I am glad
to provide it. This is not based on a hunch :). I remember changing the
base-disk size multiple times (almost all the time I deploy cluster for
some practical use-case) in the last two months to run heavier loads.
Regards,
Pranav

On Tue, Apr 21, 2015 at 8:12 PM, Roger Luethi <rl at patchworkscience.org>
wrote:

> I have no strong feelings about keeping zero_empty.sh, but personally I
> would find the suggestion more compelling if it was not based on "it may
> take hours" and "I strongly believe".
>
> How about some hard data on actual benefits and costs of zero_empty.sh?
>
> On Tue, 21 Apr 2015 12:09:33 +0200, Pranav Salunke wrote:
> >    1. Time required to create base disk is increased (zeroing out takes
> >    some time)
>
> Indeed.
>
> >    2. Disk space used is the max. size of the disk - makes thin
> >    provisioning pointless. Thin provisioning of the disks is really
> useful and
> >    should be considered.
>
> So in practical terms, what could we do that we cannot do right now?
>
> >    3. Increasing the disk space will significantly increase the time
> taken
> >    for creating the base-disk and hence it may take hours for a cluster
> having
> >    50+GB disk size.
>
> That's not likely to be the default anytime soon, and if somebody wants
> to build a large cluster, they can always comment the script out.
>
> >    4. Increase in the services and increasing demand to run heavier and
> >    more useful images apart from Cirros image makes this important point
> to
> >    consider.
>
> Okay, that's really still point 3.
>
> > I strongly believe that the loss in compression would be insignificant as
> > compared to the other benefits. I would like to hear from our team about
> > this.
>
> As I said, I don't care much either way. But I would like us to make
> informed decisions, or at least be honest about it if we are acting based
> on a hunch :-).
>
> Roger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20150422/c231bb5a/attachment.html>