Closed Bug 1170244 Opened 6 years ago Closed 5 years ago

Copying Files to SD Card is Painfully Slow


(Firefox OS Graveyard :: Hardware, defect, P3)

Gonk (Firefox OS)



blocking-b2g 2.5?


(Reporter: padamczyk, Unassigned)



Copying files to an SD card is painfully slow.
I am using a Kingston 8GB Class 4 card, it takes about 30 minutes to copy about 1 GB of data (2-3 video files) to the device. 

I am copying from a Mac, I believe I am doing it through mass storage, I am using the default Firefox OS settings (just enabled USB storage in Settings). As a reference copying to my Nexus 5 running android or to a micro SD adapter results in a 3-4 minute copy time (10x faster) also I tried several class 4 cards.

This appears to be an issue on Aries and the Flame, maybe other devices too.
Alex, Dave, could you guys take a look at this?
blocking-b2g: --- → spark?
Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(dhylands)
If it's happening already with a Flame, then I don't see anything specific to Z3c and I cannot help. That being said, as far as I know, Nexus 5 running Android do not have UMS not even a sdcard, so I don't think the test is relevant. Also, the speed factor could come from write cache in action ...

So the test to be meaning full should be:
 - Z3c running Android, then B2G
 - Sharing over UMS, with a fresh clean vfat filesystem
 - Copying a big file
 - Making sure |sync| of write cache is finished
Flags: needinfo?(lissyx+mozillians)
Please see comment 2.
blocking-b2g: spark? → spark+
Keywords: qawanted
I haven't been able to get UMS to work on the external sdcard. Were you using MTP? I'm investigating the UMS issue over in bug 1169815
Depends on: 1169815
Flags: needinfo?(dhylands)
Well I can't explain it. I did the following tests, copying a 508Mb file from my linux host to an 8Gb class 4 sdcard.

1 - Mounted external card using UMS

> time (cp boot-repair-disk-64bit.iso /media/dhylands/5E43-12F7/boot-repair-disk-64bit.iso; sync)
> real	11m18.994s
> user	0m0.000s
> sys	0m0.865s

2 - My linux machine has an sdcard slot, so I tried that:

> time (cp boot-repair-disk-64bit.iso /media/dhylands/5E43-12F7/boot-repair-disk-64bit2.iso; sync)
> real	1m42.428s
> user	0m0.008s
> sys	0m0.793s

3 - I tried an external USB-to-micro USB adapter (USB 3.0)

> time (cp boot-repair-disk-64bit.iso /media/dhylands/5E43-12F7/boot-repair-disk-64bit3.iso; sync)
> real	1m41.497s
> user	0m0.000s
> sys	0m0.799s

4 - I tried a much older USB 2.0 USB-to-microSD adpater:

> time (cp boot-repair-disk-64bit.iso /media/dhylands/5E43-12F7/boot-repair-disk-64bit4.iso; sync)
> real	1m36.015s
> user	0m0.000s
> sys	0m0.704s

5 - I mounted the external sdcard on the aries using MTP:

The MTP path wound up being: /run/user/35029/gvfs/mtp:host=%5Busb%3A003%2C040%5D/sdcard1 which I cd'd to and then did:

> time (cp ~/boot-repair-disk-64bit.iso boot-repair-disk-64bit5.iso; sync)
> real	1m23.292s
> user	0m0.037s
> sys	0m0.923s

I suspect hat there is some caching happening on the phone - the sync is only ensuring the data has left the host. It wouldn't have actually all been written to the filesystem on the phone yet.

6 - I tried UMS again just to make sure it wasn't a "first-time effect"

> time (cp boot-repair-disk-64bit.iso /media/dhylands/5E43-12F7/boot-repair-disk-64bit6.iso; sync)
> real	4m25.862s
> user	0m0.000s
> sys	0m0.807s

7 - I copied the file from the external card to the internal card inside an adb shell and then copied it back (so the source should have been coming from cache):

> time (cp /storage/sdcard0/boot-repair-disk-64bit.iso /storage/sdcard1/boot-repair-disk-64bit7.iso; sync)
>     1m45.22s real     0m0.01s user     0m3.36s system

So there you have it. Making MTP be the default seems like a reasonable thing to do.
(In reply to Dave Hylands [:dhylands] from comment #5)
> So there you have it. Making MTP be the default seems like a reasonable
> thing to do.

This will be done in bug 1171556.
See Also: → 1171556
blocking-b2g: spark+ → 2.5+
Is QA Wanted still needed or has this bug been resolved?
I think Dave's comment 5 sufficiently covered the qawanted request, not sure if they are satisfied with bug 1171556 being the whole solution though.
Keywords: qawanted
Hardware relevant bug? Is it still a blocker?
blocking-b2g: 2.5+ → 2.5?
Priority: -- → P3
Can you verify again with MTP and confirm if the issue still exists?

Flags: needinfo?(padamczyk)
Appears to be working as expected (fairly quick). Thanks!
Closed: 5 years ago
Flags: needinfo?(padamczyk)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.