<div dir="ltr">Hoi,<div>Maybe an impact analysis has been done on the consequences of downtime of Labs servers.</div><div>I would be interesting to see the analysis about the loss of data currently held on the Labs servers</div><div>It would be interesting to learn how many people are affected</div><div>It would be interesting to learn what the impact is on the maintenance of the "production" servers / applications</div><div>It might make it necessary to reassess what production means.</div><div>It might provide the reasons to reassess current practices..</div><div><br></div><div>Who is responsible for the continuity of the labs servers... NO they are not the LABS operators they are not equipped to handle the work load as is.. Who needs to know these answers ?</div><div>Thanks,</div><div>      GerardM</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 February 2015 at 18:18, Andrew Bogott <span dir="ltr"><<a href="mailto:abogott@wikimedia.org" target="_blank">abogott@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2/21/15 2:29 AM, Petr Bena wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
RANT 2<br>
<br>
Why don't we investigate what is taking so much space there? AFAIK<br>
it's 30TB storage, it shouldn't be filling up rapidly, isn't that just<br>
some broken tool that infinitely writes garbage to /data/project?<br>
</blockquote></span>
There was such a project, but I killed it a couple of weeks ago. Today, the file server looks like this:<br>
<br>
/dev/mapper/os-var          92G  3.2G   84G   4% /var<br>
/dev/mapper/store-project   30T   15T   16T  49% /srv/project<br>
/dev/mapper/store-keys     960M   47M  913M   5% /srv/keys<br>
/dev/md123                 7.3T  958G  6.3T  13% /srv/scratch<br>
<br>
Pleasingly, there aren't really any giant, serious offenders in that 15T -- usage is distributed fairly well among a large number of projects, with the biggest user being (understandably) Tools.<br>
<br>
So, not actually full.  Still, 50% full is full enough to start looking towards future expansion.  It's unfortunate that this window is right on the heels of our outage last week, but it needs to happen and I can't think of any reason why it would be better to postpone it.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If puppet was written in proper language (C++) we wouldn't need more RAM :P<br>
</blockquote></span>
That is hard to disagree with!  Still, virt1000 has been struggling and underpowered for quite a while now, and the 5 minutes that it'll take to drop in more RAM will be /much/ less disruptive than a rewrite of our server admin software :)<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Labs-l mailing list<br>
<a href="mailto:Labs-l@lists.wikimedia.org" target="_blank">Labs-l@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/labs-l" target="_blank">https://lists.wikimedia.org/<u></u>mailman/listinfo/labs-l</a><br>
</div></div></blockquote></div><br></div>