You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@apache.org by Justin Mason <jm...@jmason.org> on 2009/07/29 12:51:45 UTC
freeing up space on hudson.zones
hi Infra. as far as I can tell, all builds have been failing on
Hudson for the last couple of days due to this out-of-space condition.
I've removed the backups of the home dirs, but it hasn't resolved it.
As before, "zone-level" df indicates plenty of free space, but I
guess it's the "backing" zfs volume that's full. Is there anything I
can do to resolve this, or does it need infra fixing?
I'm hesitant to remove historic build logs, as there's no indication
yet that that would help, and I know we in SA tend to link to those in
our bug reports (as a "safe", public example of test failure) when
issues arise; I think it's likely other projects do the same.
--
--j.
Re: freeing up space on hudson.zones
Posted by Justin Mason <jm...@jmason.org>.
hmm
On Wed, Jul 29, 2009 at 14:50, Mads Toftum<ma...@toftum.dk> wrote:
> On Wed, Jul 29, 2009 at 02:04:42PM +0200, Mads Toftum wrote:
>> There is free space. Just to test, I ran mkfile of 1g as the hudson user
>> in that dir. No problem. Plonking in a 25G file in the same zpool worked
>> just as well.
>>
> Closer looking found the confluence-test zone soaking most of memory on
> the machine. That's been stopped now and by the looks of it, resource
> usage in the hudson zone is up.
Aha. that could explain it. the ENOSPC errors I was seeing were
probably referring to OOM conditions (confusingly).
--
--j.
Re: freeing up space on hudson.zones
Posted by Mads Toftum <ma...@toftum.dk>.
On Wed, Jul 29, 2009 at 02:04:42PM +0200, Mads Toftum wrote:
> There is free space. Just to test, I ran mkfile of 1g as the hudson user
> in that dir. No problem. Plonking in a 25G file in the same zpool worked
> just as well.
>
Closer looking found the confluence-test zone soaking most of memory on
the machine. That's been stopped now and by the looks of it, resource
usage in the hudson zone is up.
vh
Mads Toftum
--
http://soulfood.dk
Re: freeing up space on hudson.zones
Posted by Mads Toftum <ma...@toftum.dk>.
On Wed, Jul 29, 2009 at 11:51:45AM +0100, Justin Mason wrote:
> hi Infra. as far as I can tell, all builds have been failing on
> Hudson for the last couple of days due to this out-of-space condition.
> I've removed the backups of the home dirs, but it hasn't resolved it.
> As before, "zone-level" df indicates plenty of free space, but I
> guess it's the "backing" zfs volume that's full. Is there anything I
> can do to resolve this, or does it need infra fixing?
>
There is free space. Just to test, I ran mkfile of 1g as the hudson user
in that dir. No problem. Plonking in a 25G file in the same zpool worked
just as well.
Settings:
# zfs get all zonestorage/hudson
NAME PROPERTY VALUE SOURCE
zonestorage/hudson type filesystem -
zonestorage/hudson creation Thu Jan 17 16:36 2008 -
zonestorage/hudson used 189G -
zonestorage/hudson available 220G -
zonestorage/hudson referenced 189G -
zonestorage/hudson compressratio 1.00x -
zonestorage/hudson mounted yes -
zonestorage/hudson quota none default
zonestorage/hudson reservation none default
zonestorage/hudson recordsize 128K default
zonestorage/hudson mountpoint /zonestorage/hudson default
zonestorage/hudson sharenfs off default
zonestorage/hudson checksum on default
zonestorage/hudson compression off default
zonestorage/hudson atime on default
zonestorage/hudson devices off temporary
zonestorage/hudson exec on default
zonestorage/hudson setuid on default
zonestorage/hudson readonly off default
zonestorage/hudson zoned on local
zonestorage/hudson snapdir hidden default
zonestorage/hudson aclmode groupmask default
zonestorage/hudson aclinherit secure default
zonestorage/hudson canmount on default
zonestorage/hudson shareiscsi off default
zonestorage/hudson xattr on default
vh
Mads Toftum
--
http://soulfood.dk