Closed Bug 853502 Opened 13 years ago Closed 13 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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: