DXR builds failing with out-of-disk-space

RESOLVED FIXED

Status

RESOLVED FIXED
6 years ago
6 months ago

People

(Reporter: jcranmer, Assigned: bhearsum)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Any idea how much space a successful dxr build would need? We currently ensure we have 4gb, need to bump the "-s" argument to https://hg.mozilla.org/build/tools/file/default/scripts/dxr/dxr.sh#l39 to a better value.

Updated

6 years ago
Blocks: 803530
(Reporter)

Comment 2

6 years ago
Offhand, no. Try 6GB for now?
(Assignee)

Updated

6 years ago
Assignee: nobody → bhearsum
Created attachment 677531 [details] [diff] [review]
bump to 6
Attachment #677531 - Flags: review?(catlee)

Updated

6 years ago
Attachment #677531 - Flags: review?(catlee) → review+
(Assignee)

Updated

6 years ago
Attachment #677531 - Flags: checked-in+
OK, I triggered a new build with this checked in.
https://tbpl.mozilla.org/php/getParsedLog.php?id=16669077&tree=Firefox

10.49 GB of space available
...
gzip: stdout: No space left on device
(Reporter)

Comment 6

6 years ago
The output tarball takes up ~400MB of space (round up to find space padding needed for extra mozilla-central code). Disk-space ran out somewhere during www/ indexing, so 10.5 GB gives us enough space to at least build and do the sqlite-generation for indexing. du -s -h of the last extracted successful tarball comes out to 2.2 GB (of which ~650MB comes from the .dxr_xref directory that should already build). Total necessary space then comes out to 10.5 + 0.4 + 2.2 - .65 = 12.45 (which ought to guarantee that it doesn't run out of space). Given how far we get, I think we might be able to fit in 12GB, but 13GB should make things work easily on the safe side...
(In reply to Joshua Cranmer [:jcranmer] from comment #6)
> The output tarball takes up ~400MB of space (round up to find space padding
> needed for extra mozilla-central code). Disk-space ran out somewhere during
> www/ indexing, so 10.5 GB gives us enough space to at least build and do the
> sqlite-generation for indexing. du -s -h of the last extracted successful
> tarball comes out to 2.2 GB (of which ~650MB comes from the .dxr_xref
> directory that should already build). Total necessary space then comes out
> to 10.5 + 0.4 + 2.2 - .65 = 12.45 (which ought to guarantee that it doesn't
> run out of space). Given how far we get, I think we might be able to fit in
> 12GB, but 13GB should make things work easily on the safe side...

Thanks for the info Joshua. I bumped it up to 14! There's a new job running now, we'll see how it goes.
Most recent rebuild hung midbuild:
essed kind ClassTemplate
nsGNOMEShellService.cpp
Makefile:137: browser_459906.js is disabled for intermittent failures. Bug 766044
/builds/slave/dxr-mozilla-central/dxr-build-env/src/browser/components/BrowserComponents.manifest: WARNING: no useful preprocessor directives found
eParm
Unprocessed /builds/slave/dxr-mozilla-central/dxr-build-env/src/browser/locales/en-US/searchplugins/bing.xml: WARNING: no preprocessor directives found
/builds/slave/dxr-mozilla-central/dxr-build-env/src/browser/locales/en-US/searchplugins/eBay.xml: WARNING: no preprocessor directives found
kind ClassTemplate
/builds/slave/dxr-mozilla-central/dxr-build-env/src/browser/locales/en-US/searchplugins/twitter.xml: WARNING: no preprocessor directives found
/builds/slave/dxr-mozilla-central/dxr-build-env/src/browser/locales/en-US/searchplugins/wikipedia.xml: WARNING: no preprocessor directives found
/builds/slave/dxr-mozilla-central/dxr-build-env/src/browser/locales/en-US/searchplugins/yahoo.xml: WARNING: no preprocessor directives found
nsModule.cpp
/bu

Unlikely to be related to disk space, trying again....
My build hung again. I filed bug 808156 on that.
Looks like this worked, I see green builds.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.