<div dir="ltr">Igor,<div><br></div><div>I meant that symlinks also give us the benefit of not using additional space (just as hardlinks do) while being able to link to files from different filesystems.</div><div><br></div><div>Also, as Barłomiej pointed out the `h` switch for tar should do the trick [1].</div><div><br></div><div>Cheers,</div><div>Maciej</div><div><br></div><div>[1] <a href="http://www.gnu.org/software/tar/manual/html_node/dereference.html">http://www.gnu.org/software/tar/manual/html_node/dereference.html</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 11:22 AM, Bartlomiej Piotrowski <span dir="ltr"><<a href="mailto:bpiotrowski@mirantis.com" target="_blank">bpiotrowski@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Igor,<div><br></div><div>I took a glance on Maciej's patch and it adds a switch to tar command to make it follow symbolic links, so it looks good to me.</div><div><br></div><div>Bartłomiej</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 10:39 AM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Maceij -<br>
<span><br>
> About hardlinks - wouldn't it be better to use symlinks?<br>
> This way we don't occupy more space than necessary<br>
<br>
</span>AFAIK, hardlinks won't occupy much space. They are the links, after all. :)<br>
<br>
As for symlinks, I'm afraid shotgun (and fabric underneath) won't<br>
resolve them and links are get to snapshot As Is. That means if there<br>
will be no content in the snapshot they are pointing to, they are<br>
simply useless. Needs to be checked, though.<br>
<span><font color="#888888"><br>
- Igor<br>
</font></span><div><div><br>
On Thu, Jan 14, 2016 at 10:31 AM, Maciej Kwiek <<a href="mailto:mkwiek@mirantis.com" target="_blank">mkwiek@mirantis.com</a>> wrote:<br>
> Thanks for your insight guys!<br>
><br>
> I agree with Oleg, I will see what I can do to make this work this way.<br>
><br>
> About hardlinks - wouldn't it be better to use symlinks? This way we don't<br>
> occupy more space than necessary, and we can link to files and directories<br>
> that are in other block device than /var. Please see [1] review for a<br>
> proposed change that introduces symlinks.<br>
><br>
> This doesn't really give us much right now, because most of the logs are<br>
> fetched from master node via ssh due to shotgun being run in mcollective<br>
> container, but it's something! When we remove containers, this will prove<br>
> more useful.<br>
><br>
> Regards,<br>
> Maciej Kwiek<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/266964/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/266964/</a><br>
><br>
> On Tue, Jan 12, 2016 at 1:51 PM, Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>> wrote:<br>
>><br>
>> I think we need to find a way to:<br>
>><br>
>> 1) verify the size of snapshot without actually making it and compare to<br>
>> the available disk space beforehand.<br>
>> 2) refuse to create snapshot if space is insufficient and notify user<br>
>> (otherwise it breaks Admin node as we have seen)<br>
>> 3) provide a way to prioritize elements of the snapshot and exclude them<br>
>> based on the priorities or user choice.<br>
>><br>
>> This will allow for better and safer UX with the snapshot.<br>
>><br>
>> --<br>
>> Best regards,<br>
>> Oleg Gelbukh<br>
>><br>
>> On Tue, Jan 12, 2016 at 1:47 PM, Maciej Kwiek <<a href="mailto:mkwiek@mirantis.com" target="_blank">mkwiek@mirantis.com</a>> wrote:<br>
>>><br>
>>> Hi!<br>
>>><br>
>>> I need some advice on how to tackle this issue. There is a bug [1]<br>
>>> describing the problem with creating a diagnostic snapshot. The issue is<br>
>>> that /var/log has 100GB available, while /var (where diagnostic snapshot is<br>
>>> being generated - /var/www/nailgun/dump/fuel-snapshot according to [2]) has<br>
>>> 10GB available, so dumping the logs can be an issue when logs size exceed<br>
>>> free space in /var.<br>
>>><br>
>>> There are several things we could do, but I am unsure on which course to<br>
>>> take. Should we<br>
>>> a) Allocate more disk space for /var/www (or for whole /var)?<br>
>>> b) Make the snapshot location share the diskspace of /var/log?<br>
>>> c) Something else? What?<br>
>>><br>
>>> Please share your thoughts on this.<br>
>>><br>
>>> Cheers,<br>
>>> Maciej Kwiek<br>
>>><br>
>>> [1] <a href="https://bugs.launchpad.net/fuel/+bug/1529182" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1529182</a><br>
>>> [2]<br>
>>> <a href="https://github.com/openstack/fuel-web/blob/2855a9ba925c146b4802ab3cd2185f1dce2d8a6a/nailgun/nailgun/settings.yaml#L717" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-web/blob/2855a9ba925c146b4802ab3cd2185f1dce2d8a6a/nailgun/nailgun/settings.yaml#L717</a><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>