0

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?

2
  • @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
    Commented Dec 14, 2017 at 18:02
  • I found what is probably the true culprit. Comment cleanup incoming.
    – Grimoire
    Commented Dec 14, 2017 at 19:12

1 Answer 1

2

Summary

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

su
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

Conclusions

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.

4
  • 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
    Commented Dec 16, 2017 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
    Commented Dec 16, 2017 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.
    – Grimoire
    Commented Dec 16, 2017 at 12:08
  • @DeathMaskSalesman I appreciated the answer and the comments, because they are very precise and detailed: a fundamental thing for a satisfactory understanding. Thank you so for this clarification: as I said, I was not at all certain, but now the uncertainty has been completely resolved. Thus the amplification would derive from using ext4 in the specific storage supports for mobile.
    – Bento
    Commented Dec 18, 2017 at 2:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .