My phone

I own a phone with gigabytes of built-in flash memory. My phone also includes a physical MicroSD card slot. I don't own a MicroSD card to put in the slot, and have never bothered buying one, but am not opposed to the idea of buying one.

I perhaps make heavier use of my phone's flash memory than most people.

  • I run a freeware sleep tracker app most nights, all night long. It has many features. Its most storage-intensive feature? It records sound for at least part of every night.

  • I have Debian Linux installed on my phone as well (even though the phone is not rooted). I launch Debian when desired using an app named GNURoot Debian. Debian Linux is normally stored on an SSD designed to handle an enormous number of write cycles, or on a hard drive which can also handle numerous write cycles — not on a smartphone flash memory chip.

  • I have perhaps a hundred apps installed, and the Google Play store automatically updates some of them from time to time.

  • I make heavy use of a game which was designed for use on Windows and Linux, but has been ported to Android. Every time I move between floors of the game world, the game saves some information to disk. I suspect that, in practice, it rewrites at least part of the game's save file.

The problem

David Cary has more than 10,000 reputation points on Electrical Engineering Stack Exchange. In one post there, Mr. Cary writes:

Flash memory has relatively quick read times but much longer write times. For example, with a Numonyx M25P80-VMW6G 75MHz 8 Mbit serial flash, reading a sector of data (at 75 MHz) requires 7 milliseconds, while erasing and writing new data to a sector is typically 0.6 seconds (max 3 seconds).

In other words, writing this flash memory typically takes 85 times as long as reading, and in the worst case writing a sector takes over 400 times as long as reading. (That's not even taken into account the inefficiencies of partial-sector updating).

In my experience, the time it takes to erase and rewrite a particular sector of flash continues to increase with each erase/rewrite cycle, but read times stay constant.

I don't know that much about hardware, but let's assume that Mr. Cary's experience will be true for my phone too.

My question

I don't like spending money unnecessarily, and it sometimes takes me great effort to choose a phone to buy. When I buy a phone, I like to treat it well and to keep on using it for five to ten years or more — unless it breaks so badly that this becomes absolutely impossible.

Certain operations on my phone are annoyingly slow, such as Debian Linux automatic software update checks (apt-get update) and others. I don't know whether or not they're slow because of the time it takes to write to flash or because of other reasons.

Anyway, assuming that the issue which Mr. Cary has raised above is a real issue, should I worry about it? Should I change my behavior because of it — for example, by moving GNURoot Debian from the phone's built-in flash memory to a MicroSD card inserted into the correct slot?


I have left this question mostly device-agnostic. This is because I'd like to apply what I learn both to the device which I own and any other Android devices which I may buy in the future.


  • Accepted answer doesn't take erase block size into consideration. Check this or this. Also is wrong on 1M write cycle count. It is just 10k. Check write endurance section in wiki Jun 19, 2016 at 5:11

2 Answers 2


As a user, and not a developer, this is not an effect you should concern yourself with. For operations like disk defragmentation or use of flash memory as virtual memory, the sustained high disk write rates can wear out flash memory quickly. But "normal" usage by a human will not produce enough writes to create a wear issue.

Let's take the sleep app as an example and estimate how many writes this will cause on a wear-leveled disk. Suppose the app collects 128 kilobit / second audio to store uncompressed and runs and collects audio at all times for 5 years. (128 kilobits / second) * (128 bytes / kilobit) * (5 years) * (365 days / year) * (24 hours / day) * (60 minutes / hour) * (60 seconds / minute) ~= 5.17 * 10^11 bytes. On a wear leveled disk of 1 GB ~= 10^9 bytes, this will be (5.17 * 10^11) / (10^9) ~= 517 cycles over the 5 years, which is well below the expected 100,000 cycles for current flash memory.

Also, note that almost all SSDs are currently built from flash memory, so there is no significant difference between the storage for your Android phone and that in a consumer SSD for a laptop/desktop in terms of expected aging issues.


If you are really worried about this, I would benchmark your storage performance. I don't think it is a good assumption that erase/write operations take 0.6 seconds; your flash memory is not the same as that used in the example figures.

This empirical evaluation of flash memory gives actual figures for degradation. The magnitude of the effect is not that large for cycles in the low thousands.

  • For now, not upvoted. My question is not about memory failure (due to the fact that flash memory has a finite number of program–erase cycles). Instead, my question is about memory slowdown — about Mr. Cary's statement that the time it takes to erase and rewrite a particular sector of flash continues to increase with each erase/rewrite cycle. But your question talks about "memory wear", which is a term which (in my limited knowledge) is usually used in order to discuss how many cycles you can undergo before failure. Jul 30, 2015 at 20:18
  • 1
    In what situation do you expect the flash memory write times on your device to be a performance bottleneck?
    – mattm
    Jul 30, 2015 at 20:33
  • I don't know. 1) Recently, I decompressed a 27 MB compressed archive (the source code of a game, plus dependencies) in GNURoot Debian, and I was annoyed at how many minutes it took. I'm not sure whether the operation was CPU-bound or disk-bound, and didn't check. 2) Let's assume that, even on my device, erasing and writing new data to a sector takes 0.6 seconds or more. That's a long time. Is it possible that some of the software on my device (though I don't know which software) might wait for certain write operations to finish before continuing operation? Jul 30, 2015 at 20:39
  • 1
    apt-get update/upgrade is likely to be slow because of CPU (based on experience with the Raspberry Pi). Decompressing archives is pretty strenuous.
    – user43185
    Jul 31, 2015 at 7:19
  • Dear mattm: I looked at the paper you linked to. It seems that the slowdowns may be more gradual than I thought. And, as you point out, my device probably uses wear leveling, which also helps. And indeed, I suspect the flash chip which Mr. Cary used in his example is smaller (and probably older and slower) than the Samsung KLM8G2FE3B-B001 chip which is used in my Samsung Galaxy S Relay 4G. Upvoted and accepted. Thank you! Jul 31, 2015 at 17:44

I would say it depends on your hardware. For example, some Samsung devices (e.g. Note 4) are known to have eMMC flash chip that is prone to fail if too much data is written during the lifetime of the phone. I had to replace eMMC (the motherboard in practice) of my Samsung S4 Mini LTE due it failed after being written too much over time.

However, most phone hardware has too slow SD card writer for your use case, even if you get the best A1 class cards (for more information about A1 vs A2 cards for Android usage, see Should I get A1 or A2 spec'd Micro SD card for my phone?). The major problem you have is the usage of apt within the Debian installation. The apt usage is problematic because apt tries really hard to keep your system fully functional even in case of power loss during any update. As a result, it is really really sync happy and will wait for permanent storage to confirm all writes every so often before continuing.

If you can accept the possibility of losing your Debian environment due out of battery situation, you can mount your debian partition noatime,async,nobarrier and your performance should improve.

You must log in to answer this question.

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