Closed Bug 948947 Opened 10 years ago Closed 10 years ago

update.boot2gecko.org disk is filling up

Categories

(Release Engineering :: General, defect, P2)

x86_64
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: nthomas)

Details

From: check_disk@ip-10-39-70-110.ec2.internal
To: release+update.b2g.o@mozilla.com
Subject: Warning: /data over 85 full (85%)

2013-12-11
ip-10-39-70-110.ec2.internal

Disk space
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  5.9G  2.0G  75% /
tmpfs                 3.4G     0  3.4G   0% /dev/shm
/dev/xvdf1             32G   26G  4.7G  85% /data

Inodes
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/xvda1              512K    126K    387K   25% /
tmpfs                   870K       1    870K    1% /dev/shm
/dev/xvdf1              2.0M    2.3K    2.0M    1% /data
jgriffin, I hear this is one of our vms. Can you find someone to look into it?
Flags: needinfo?(jgriffin)
This is the server that B2G updates are hosted on for dogfooding.

We really need to get b2g-release-drivers to form a policy about how long these should be retained; I'd guess old ones could be safely deleted, but I wouldn't want to do that without confirmation.  

Depending on what they say, we could make a cron job to delete old jobs.  I'll send a note to b2g-release-drivers.
Flags: needinfo?(jgriffin)
(In reply to Jonathan Griffin (:jgriffin) from comment #2)
> This is the server that B2G updates are hosted on for dogfooding.
> 
> We really need to get b2g-release-drivers to form a policy about how long
> these should be retained; I'd guess old ones could be safely deleted, but I
> wouldn't want to do that without confirmation.  
> 
> Depending on what they say, we could make a cron job to delete old jobs. 
> I'll send a note to b2g-release-drivers.

Per email discussion on b2g-r-d@, we can go ahead and start deleting old builds to free up space. QA haven't used OTA updates internally since 1.0.1 -> 1.1 days, because the devices they now test on dont seem to work correctly with it (ie: Buris).  

The "real" longer term solution here is to serve these updates from Balrog. See bug#918068 for details.
Assignee: nobody → nthomas
Priority: -- → P2
Turns out we weren't including the /data/update-channels/mako/ dir in the cron job that's removing updates older than two weeks, so I've fixed that. I had manually trimmed harder than that, but when it fills up again we should end up at about 10G, or 30%, free.

BTW, we don't have mako configured in the apache config, so no updates are being served for that.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.