Closed Bug 853502 Opened 9 years ago Closed 9 years ago

Report disk partition fullness during automated tests

Categories

(Testing :: General, defect)

x86
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla22

People

(Reporter: gbrown, Assigned: gbrown)

Details

Attachments

(1 file)

If a disk partition becomes full during a test, various failures may result:
 - application installation failure
 - profile creation failure
 - disk cache write failure
 - database update failure
My recent experience with a nearly-full /data partition suggests that some of these failures can go undetected, resulting in seemingly random test failures.

How full are the partitions on the tegras and pandas normally? During tests? What if something goes wrong and we log a lot more than usual?

I would like to add disk partition info to our test logs -- maybe just add df output to the existing sutagent DEVINFO command.
There was some existing support for reporting disk usage, but it wasn't complete. I have changed it to my liking -- what do you think?

$>disk
/: 0 total, 0 available
$>disk /data
/data: 221773824 total, 92045312 available
$>disk /mnt/sdcard
/mnt/sdcard: 7949434880 total, 7897075712 available
$>info disk

/data: 221773824 total, 92045312 available
/system: 250740736 total, 150310912 available
/mnt/sdcard: 7949434880 total, 7897075712 available
$>info
00:26:e8:d4:1a:e4
harmony-eng 2.2 FRF91 20110202.102810 test-keys
1970/01/01 03:44:24:441
0 days 3 hours 44 minutes 8 seconds 38 ms
13448040
X:1024 Y:768
ROTATION:0
PA:808591360, FREE: 693473280
Power status:
  AC power ONLINE
  Battery charge NO BATTERY
  Remaining charge:      0%
  Battery Temperature:   0.0 (c)

Temperature: unknown
10031	11040	com.mozilla.SUTAgentAndroid
10018	1266	com.android.launcher
10026	1582	com.svox.pico
10007	1245	com.android.inputmethod.latin
1001	1255	com.android.phone
1000	1025	system
10028	1533	com.android.defcontainer
10035	7683	org.mozilla.f3nn3c_mozdev.UpdateService
10033	1968	org.mozilla.fencp
10013	1501	com.cooliris.media
10004	1428	android.process.media
10009	1483	com.android.quicksearchbox
10002	1493	com.android.music
10032	1473	com.mozilla.watcher
10006	1440	com.android.mms
10010	1414	com.android.providers.calendar
10014	1400	com.android.email
10017	1392	com.android.bluetooth
10029	1383	com.android.deskclock

/data: 221773824 total, 92045312 available
/system: 250740736 total, 150310912 available
/mnt/sdcard: 7949434880 total, 7897075712 available
$>
Assignee: nobody → gbrown
Attachment #728374 - Flags: review?(jmaher)
Attachment #728374 - Flags: feedback?(wlachance)
Comment on attachment 728374 [details] [diff] [review]
improve sutagent DISK commands

I like it. Don't forget to update mozdevice as well so we have an API to this data!
Attachment #728374 - Flags: feedback?(wlachance) → feedback+
Comment on attachment 728374 [details] [diff] [review]
improve sutagent DISK commands

Review of attachment 728374 [details] [diff] [review]:
-----------------------------------------------------------------

thanks!
Attachment #728374 - Flags: review?(jmaher) → review+
(In reply to William Lachance (:wlach) from comment #2)
> I like it. Don't forget to update mozdevice as well so we have an API to
> this data!

Thanks Will. Actually, mozdevice already supports getInfo("disk") -- I think there's no need for mozdevice changes in this case.
https://hg.mozilla.org/mozilla-central/rev/a90c916de9d3
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
You need to log in before you can comment on or make changes to this bug.