1170244 - Copying Files to SD Card is Painfully Slow

Status: RESOLVED FIXED

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

Description

[Patryk Adamczyk [:patryk] UX]

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.

Comment 1

[Doug Sherk (:drs) (inactive)]

Alex, Dave, could you guys take a look at this?

Comment 2

[Alexandre LISSY :gerard-majax]

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

Comment 3

[Doug Sherk (:drs) (inactive)]

Please see comment 2.

Comment 4

[Dave Hylands [:dhylands]]

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

Comment 5

[Dave Hylands [: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.

Comment 6

[Doug Sherk (:drs) (inactive)]

(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.

Comment 7

[sshir]

Is QA Wanted still needed or has this bug been resolved?

Comment 8

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

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.

Comment 9

[Ken Chang[:kenkai]]

Hardware relevant bug? Is it still a blocker?

Comment 10

[Mahendra Potharaju [:mahe]]

Can you verify again with MTP and confirm if the issue still exists?

Thanks

Comment 11

[Patryk Adamczyk [:patryk] UX]

Appears to be working as expected (fairly quick). Thanks!