Why, in particular from Android 6 (for 5 version I don't know, but surely not for the 4.x and minors) is there an excessive slowness for trivial operations on a folder (e.g. renaming a folder or paste its content) when it contains many many very small files?

This seems to me a tragic deterioration of system performance. What had Google programmers in mind when they designed these versions?

  • @beeshyams Yes, I use that. I tried with several file m., but always the problem persists. In the past I received a useful hint here in S.E., someone suggested me to use ADB. This effectively solves the problem, but it is a bit uncomfortable to use PC anytime I have such a kind of folder, moreover the question had remained: why this change in performance? The reference to GG programmers imho is not so out of the context: First, how can you assert an absolute absence of some GG programmer or someone in some relationship with them? Secondly, nothing polemical, but simply: what their aim? – Bento Dec 14 '17 at 18:02
  • I found what is probably the true culprit. Comment cleanup incoming. – Death Mask Salesman Dec 14 '17 at 19:12


This issue is probably caused by Android allowing access to the internal storage via FUSE (Filesystem in USErspace), as the internal storage itself is just a subdirectory of the /data partition.

Test conditions

These tests have been performed on LineageOS 14.1 (Android 7.1.2), via the Termux terminal emulator, using a directory called test which contained 9414 files whose size ranged from one to five bytes. The underlying /data partition was formatted as ext4.

I am not affiliated to either Termux or its author.

First test

The commands used were

cd /sdcard
time cp -r test test2

Which returned an elapsed time of

real    1m10.477s
user    0m0.595s
sys     0m3.360s

The directory test2 was deleted after confirming the results.

Second test

The commands used were

cd /data/media/0
time cp -r test test2

Basically, what I did here was to move to the /data subdirectory which contains the actual internal storage. The results of this test follow.

0m07.06s real     0m00.14s user     0m06.18s system


Given the huge discrepancy in the time elapsed while copying data on FUSE and while doing the same on ext4 directly, I assume that the culprit be the overhead generated by FUSE itself.

  • Upvoted for nice sleuthing – beeshyams Dec 15 '17 at 10:44
  • Sleuthing is fun, @beeshyams. – Death Mask Salesman Dec 15 '17 at 10:45
  • so this is the offending element.. so it's its mechanism that suffers when you're in the presence of fragmented files (ie, I mean, not all arranged contiguously on a segment of memory - note that I'm not at all sure of my consideration), while there are no problems involved individual files (small or large) that require a single linear block (in fact, for similar operations on, for example, multimedia files even larger than the offending folder, very short times are required). – Bento Dec 16 '17 at 2:03
  • 1
    Incredible that the mechanism amplify exponentially the duration: based on what has been described, it seems that increasing the number of elements for which access must be granted, time is affected exponentially. Thank you very much for the clarification. – Bento Dec 16 '17 at 2:03
  • 1
    @Bento As I said in the comments, the kind of memory that's installed in a mobile device (eMMC), just as SSD drives, does not suffer from fragmentation, because there are no spinning parts, which are indeed present in a traditional hard disk drive. Any block can be accessed in virtually the same amount of time in eMMC drives, hence fragmentation is irrelevant. It would be interesting to study the repercussions of using the ext4 filesystem, which was designed with mechanical hard disk drives in mind, on eMMCs. You may want to look up the f2fs filesystem, if this topic interests you. – Death Mask Salesman Dec 16 '17 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.