<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 19, 2018 at 5:58 PM, Nithya Balachandran <span dir="ltr"><<a href="mailto:nbalacha@redhat.com" target="_blank">nbalacha@redhat.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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 19 February 2018 at 13:12, Atin Mukherjee <span dir="ltr"><<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Feb 19, 2018 at 8:53 AM, Nigel Babu <span dir="ltr"><<a href="mailto:nigelb@redhat.com" target="_blank">nigelb@redhat.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"><div><div>Hello,<br><br></div>As you all most likely know, we store the tarball of the binaries and core if there's a core during regression. Occasionally, we've introduced a bug in Gluster and this tar can take up a lot of space. This has happened recently with brick multiplex tests. The build-install tar takes up 25G, causing the machine to run out of space and continuously fail.<br></div></div></blockquote><div><br></div></span><div>AFAIK, we don't have a .t file in upstream regression suits where hundreds of volumes are created. With that scale and brick multiplexing enabled, I can understand the core will be quite heavy loaded and may consume up to this much of crazy amount of space. FWIW, can we first try to figure out which test was causing this crash and see if running a gcore after a certain steps in the tests do left us with a similar size of the core file? IOW, have we actually seen such huge size of core file generated earlier? If not, what changed because which we've started seeing this is something to be invested on.<br></div></div></div></div></blockquote><div><br></div></span><div>We also need to check if this is only the core file that is causing the increase in size or whether there is something else that is taking up a lot of space. </div><span class=""></span><br clear="all"></div></div></div></blockquote></div><br></div><div class="gmail_extra">I don't disagree. However there are two problems here. In the few cases where we've had such a large build-install tarball,<br><br>1. The tar doesn't actually finish being created. So it's not even something that can be untar'd. It would just error out.<br></div><div class="gmail_extra">2. All subsequent jobs on this node fail.<br><br></div><div class="gmail_extra">The only remaining option is to watch out for situations when the tar file doesn't finish creation and highlight it. When we moved to chunked regressions, the nodes do not get re-used, so 2 isn't a problem.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">nigelb<br></div></div>
</div></div>