794397 - API to get the total capacity of the SD card

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect, P4)

Description

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

The story is to have a usage bar for the SD card in "Media Storage" section of settings app.
- Please refer to P.17 of
  http://people.mozilla.org/~lco/Settings_B2G/Release_1_Specs/R1_Device_v3.pdf


So far we could only get free/used size for each type of device Storage, like video/music/photo.

Corresponding Gaia issue:
https://github.com/mozilla-b2g/gaia/issues/3971

Comment 1

[Andrew Overholt [:overholt]]

Doug, can this make feature freeze?

Comment 2

[Andrew Overholt [:overholt]]

Since this blocks some gaia features, I think we should block on it.  Plus Doug said he hopes to get to it today :)

Comment 3

[Dietrich Ayala (:dietrich)]

Hey Doug, what's the ETA for this?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We currently have APIs for getting the total amount of used space, and total amount of free space. The former is implemented by going through all directories and stat()ing all files and summing up their size. The latter is done by stat()ing the volume and asking for amount of free space.

In the UI that we are planning on showing we show total size, used size and free size. Doing that is currently possible by simply calling the two functions above and then adding those numbers up.

However it would be a whole lot faster if we also had an API for stat()ing the volume and asking it for its total size.

That way you could just ask for volume size and free size. And then subtracting to get used size.


So I'm not convinced that this is a blocker still since you now can implement the required UI. But it would be a nice performance enhancement to fix this.

Based on that I'm punting this to blocking- but leaving assigned to Doug so he can do this if he has free cycles.

Comment 5

[Doug Turner (:dougt)]

I think rudy now has everything he needs to implement this feature as spec'ed out in P.17.

Rudy, please reopen if you disagree.  (or find me on irc if you don't know what Im talking about :) )

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't think this bug in INVALID given that there is a pretty dramatic performance difference between just stat()ing the volume vs. stat()ing each file. So I think we'll want to fix this eventually. But I think blocking- is appropriate unless we find that the current solution is simply too slow (at which point people can renominate this)

Comment 7

[Dietrich Ayala (:dietrich)]

Why was this changed to blocking+?

Also, given that this is new, it should be P1 to reflect the risk that any feature work has at this point.

(Please always add a comment, however short, explaining rationale for marking blocking or not. It really reduces communication churn.)

Comment 8

[Doug Turner (:dougt)]

dietrich, see bug 805718 which blocks this bug (which is blocking-basecamp+)

Comment 9

[Doug Turner (:dougt)]

s/blocks this/depends on this

Comment 10

[Dietrich Ayala (:dietrich)]

Been >2 weeks - any update Doug?

Comment 11

[Andrew Overholt [:overholt]]

Here we say it depends upon bug 805718 but in that bug Kaze says we just need to fix this bug :)

Renomming for discussion at triage.

Comment 12

[Andrew Overholt [:overholt]]

Doug described this is simply a round-off error.  I'm marking this as a soft blocker.

Comment 13

[Doug Turner (:dougt)]

Attachment: work in progress - patch v.0

minused.  attaching what work i did already.  Basically what has to happen next is that we should not use the volume manager, but instead just call statfs() directly.

Comment 14

[Doug Turner (:dougt)]

unassigning things that I am not working on.

Comment 15

[BMO Automation]

Firefox OS is not being worked on