Closed
Bug 948947
Opened 10 years ago
Closed 10 years ago
update.boot2gecko.org disk is filling up
Categories
(Release Engineering :: General, defect, P2)
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)
Comment 2•10 years ago
|
||
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)
Comment 3•10 years ago
|
||
(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 | ||
Updated•10 years ago
|
Assignee: nobody → nthomas
Priority: -- → P2
Assignee | ||
Comment 4•10 years ago
|
||
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
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•