Closed
Bug 1170244
Opened 6 years ago
Closed 5 years ago
Copying Files to SD Card is Painfully Slow
Categories
(Firefox OS Graveyard :: Hardware, defect, P3)
Tracking
(blocking-b2g:2.5?)
RESOLVED
FIXED
blocking-b2g | 2.5? |
People
(Reporter: padamczyk, Unassigned)
References
Details
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•6 years ago
|
||
Alex, Dave, could you guys take a look at this?
blocking-b2g: --- → spark?
Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(dhylands)
Comment 2•6 years ago
|
||
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)
Comment 4•6 years ago
|
||
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)
Comment 5•6 years ago
|
||
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•6 years ago
|
||
(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+
Comment 8•6 years ago
|
||
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
Comment 9•5 years ago
|
||
Hardware relevant bug? Is it still a blocker?
blocking-b2g: 2.5+ → 2.5?
Priority: -- → P3
Comment 10•5 years ago
|
||
Can you verify again with MTP and confirm if the issue still exists? Thanks
Flags: needinfo?(padamczyk)
Reporter | ||
Comment 11•5 years ago
|
||
Appears to be working as expected (fairly quick). Thanks!
Status: NEW → RESOLVED
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.
Description
•