> I took a glance on Maciej's patch and it adds a switch to tar command > to make it follow symbolic links
Yeah, that should work. Except one thing - we previously had fqdn -> ipaddr links in snapshots. So now they will be resolved into full copy? > 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. I'm sorry, I got you wrong. :) - Igor On Thu, Jan 14, 2016 at 12:34 PM, Maciej Kwiek <mkw...@mirantis.com> wrote: > Igor, > > 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. > > Also, as Barłomiej pointed out the `h` switch for tar should do the trick > [1]. > > Cheers, > Maciej > > [1] http://www.gnu.org/software/tar/manual/html_node/dereference.html > > On Thu, Jan 14, 2016 at 11:22 AM, Bartlomiej Piotrowski > <bpiotrow...@mirantis.com> wrote: >> >> Igor, >> >> 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. >> >> Bartłomiej >> >> On Thu, Jan 14, 2016 at 10:39 AM, Igor Kalnitsky <ikalnit...@mirantis.com> >> wrote: >>> >>> Hey Maceij - >>> >>> > About hardlinks - wouldn't it be better to use symlinks? >>> > This way we don't occupy more space than necessary >>> >>> AFAIK, hardlinks won't occupy much space. They are the links, after all. >>> :) >>> >>> As for symlinks, I'm afraid shotgun (and fabric underneath) won't >>> resolve them and links are get to snapshot As Is. That means if there >>> will be no content in the snapshot they are pointing to, they are >>> simply useless. Needs to be checked, though. >>> >>> - Igor >>> >>> On Thu, Jan 14, 2016 at 10:31 AM, Maciej Kwiek <mkw...@mirantis.com> >>> wrote: >>> > Thanks for your insight guys! >>> > >>> > I agree with Oleg, I will see what I can do to make this work this way. >>> > >>> > About hardlinks - wouldn't it be better to use symlinks? This way we >>> > don't >>> > occupy more space than necessary, and we can link to files and >>> > directories >>> > that are in other block device than /var. Please see [1] review for a >>> > proposed change that introduces symlinks. >>> > >>> > This doesn't really give us much right now, because most of the logs >>> > are >>> > fetched from master node via ssh due to shotgun being run in >>> > mcollective >>> > container, but it's something! When we remove containers, this will >>> > prove >>> > more useful. >>> > >>> > Regards, >>> > Maciej Kwiek >>> > >>> > [1] https://review.openstack.org/#/c/266964/ >>> > >>> > On Tue, Jan 12, 2016 at 1:51 PM, Oleg Gelbukh <ogelb...@mirantis.com> >>> > wrote: >>> >> >>> >> I think we need to find a way to: >>> >> >>> >> 1) verify the size of snapshot without actually making it and compare >>> >> to >>> >> the available disk space beforehand. >>> >> 2) refuse to create snapshot if space is insufficient and notify user >>> >> (otherwise it breaks Admin node as we have seen) >>> >> 3) provide a way to prioritize elements of the snapshot and exclude >>> >> them >>> >> based on the priorities or user choice. >>> >> >>> >> This will allow for better and safer UX with the snapshot. >>> >> >>> >> -- >>> >> Best regards, >>> >> Oleg Gelbukh >>> >> >>> >> On Tue, Jan 12, 2016 at 1:47 PM, Maciej Kwiek <mkw...@mirantis.com> >>> >> wrote: >>> >>> >>> >>> Hi! >>> >>> >>> >>> I need some advice on how to tackle this issue. There is a bug [1] >>> >>> describing the problem with creating a diagnostic snapshot. The issue >>> >>> is >>> >>> that /var/log has 100GB available, while /var (where diagnostic >>> >>> snapshot is >>> >>> being generated - /var/www/nailgun/dump/fuel-snapshot according to >>> >>> [2]) has >>> >>> 10GB available, so dumping the logs can be an issue when logs size >>> >>> exceed >>> >>> free space in /var. >>> >>> >>> >>> There are several things we could do, but I am unsure on which course >>> >>> to >>> >>> take. Should we >>> >>> a) Allocate more disk space for /var/www (or for whole /var)? >>> >>> b) Make the snapshot location share the diskspace of /var/log? >>> >>> c) Something else? What? >>> >>> >>> >>> Please share your thoughts on this. >>> >>> >>> >>> Cheers, >>> >>> Maciej Kwiek >>> >>> >>> >>> [1] https://bugs.launchpad.net/fuel/+bug/1529182 >>> >>> [2] >>> >>> >>> >>> https://github.com/openstack/fuel-web/blob/2855a9ba925c146b4802ab3cd2185f1dce2d8a6a/nailgun/nailgun/settings.yaml#L717 >>> >>> >>> >>> >>> >>> >>> >>> __________________________________________________________________________ >>> >>> OpenStack Development Mailing List (not for usage questions) >>> >>> Unsubscribe: >>> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >> >>> >> >>> >> >>> >> __________________________________________________________________________ >>> >> OpenStack Development Mailing List (not for usage questions) >>> >> Unsubscribe: >>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >>> > >>> > >>> > >>> > __________________________________________________________________________ >>> > OpenStack Development Mailing List (not for usage questions) >>> > Unsubscribe: >>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
