www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (INFRA-11743) Increase disk space allocated for Jenkins workspaces on lucene1-us-west
Date Mon, 25 Apr 2016 20:32:12 GMT

    [ https://issues.apache.org/jira/browse/INFRA-11743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256991#comment-15256991
] 

Uwe Schindler commented on INFRA-11743:
---------------------------------------

I think resizing the underlying disk image should be the easiest, because it is a separate
device (/x1 is on a separate disk /sdb), so the operating systems's root device is unaffected.
So we can easily call resize2fs or similar after fixing partition table. I can take care of
that, once the device was resized. No need to copy stuff to a completely new device.

> Increase disk space allocated for Jenkins workspaces on lucene1-us-west
> -----------------------------------------------------------------------
>
>                 Key: INFRA-11743
>                 URL: https://issues.apache.org/jira/browse/INFRA-11743
>             Project: Infrastructure
>          Issue Type: Task
>          Components: Jenkins, Zones/Jails
>            Reporter: Steve Rowe
>
> The Lucene project requests that the disk space available for Jenkins workspaces on lucene1-us-west
be increased, by at least 50%: 79GB -> 120GB.
> The Lucene project runs Jenkins builds on lucene1-us-west.apache.org (see INFRA-9096),
but we've run out of disk space a couple times in recent history, because the number of branches
we build against is increasing.
> Here's the situation on /x1, where Jenkins workspaces are:
>   $ df -k /home/jenkins/jenkins-slave/workspace/
>   Filesystem     1K-blocks     Used Available Use% Mounted on
>   /dev/sdb1       82437808 66355440  11871732  85% /x1
> Right now when we run out of disk space, we can wipe the workspaces for branches that
don't have a pending release (I did that today), but I expect this strategy to fail in the
near term, as we'll very likely have more simultaneously active release branches to test (along
with the stable and unstable branches we always build against).
> Probably the strategy that would cause the least downtime would be to resize the underlaying
VM virtual disk and then resize the file system afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message