Smartphones seem to die after two years of usage, as if they knew that you just have paid the last instalment.
The common reason seems to be the failure of internal memory.
I'm desperately trying to have my phone escaping from this cruel destiny.
The idea I initially had seemed simple, but the web didn't seem to share my optimism.
This is the idea:
- create ext4 partitions in sd card
- mount at boot sdcard partitions to /data and /cache (and maybe /preload and /efs if they ever get written)

I'd like to know what's wrong with this idea and why it cannot work, but the main question is:
Can I stop writing to internal memory for good?

I've seen all the apps out there (app2sd, link2sd, DirecoryBind, s2e , you name it) and all of them seem to relocate subdirectories, never the main /data .
Any help will be highly appreciated.
Thank you!

  • 1
    Welcome to the Android Enthusiasts! Have you tried our site's search feature, and checked behind the tags used (most of them have a wiki attached)? That question was already asked here more than once. And besides, I've got 2 Android phones I already use for 5 years and more, my current primary device I use for about 3 years. Nothing died so far (except for one SD card, which was easily replaced).
    – Izzy
    Commented Jan 6, 2016 at 15:02
  • Hi @Izzy, I've found a lot about how to increase memory, nothing answering to the actual question in the title. That's exactly my point, it's easy to throw away and replace an sd card, can't say the same about a phone
    – Claudio
    Commented Jan 6, 2016 at 15:45
  • I believe Android Marshmallow has this feature built-in but this isn't so relevant for everyone else still on Lollipop and older. Hopefully can help some users.
    – LJD200
    Commented Jan 6, 2016 at 17:42
  • @LJD200 almost right. MM allows to merge the two. But OP wants to use the external only, and not touch the internal at all – so that won't do.
    – Izzy
    Commented Jan 6, 2016 at 22:01
  • Just flashed CyanogenMod 13 (Android 6) NIGHTLY version. I was given up after 2 days of researches and unresponsive forums and I started to watch videos about replacing emmc :-) ahah ! @Izzy, a one time only write could be ok, what I want to avoid is a continuous replacement of files by apps or Android itself.
    – Claudio
    Commented Jan 6, 2016 at 22:55

3 Answers 3


Here is how I've done it:

SD card partition and format

Unsure about which partitions I would have been able to relocate, I decided to recreate my sd card with the exact same layout of my Samsung Galaxy S III internal memory.
USERDATA is the last partition and there is a good reason for it:
my sd card size is greater then the internal memory and the best option has been to widen USERDATA till the possible furthest sector.

The following work has been done in my linux pc:

parted /dev/sdb mklabel gpt \
mkpart  BOTA0      ext2     8192s          16383s \
mkpart  BOTA1      ext2    16384s          24575s \
mkpart  EFS        ext2    24576s          65535s \
mkpart  PARAM      ext2    65536s          81919s \
mkpart  BOOT       ext2    81920s          98303s \
mkpart  RECOVERY   ext2    98304s         114687s \
mkpart  RADIO      ext2   114688s         180223s \
mkpart  CACHE      ext2   180224s        2277375s \
mkpart  SYSTEM     ext2  2277376s        5423103s \
mkpart  HIDDEN     ext2  5423104s        6569983s \
mkpart  OTA        ext2  6569984s        6586367s \
mkpart  USERDATA   ext2  6586368s       60749824s

Good, partitions created.
Now, still mimicking my Android device, I format partitions accordingly:

# /efs
mkfs.ext4  /dev/sdb3   -E root_owner=1001:1000
# /system
mkfs.ext4  /dev/sdb9   -E root_owner=0:0         -L system
# /cache
mkfs.ext4  /dev/sdb8   -E root_owner=1000:2001
# /preload
mkfs.ext4  /dev/sdb10  -E root_owner=0:0
# /data
mkfs.ext4  /dev/sdb12  -E root_owner=1000:1000

The sd card is ready, now I can "backup" files from emmc to the appropriate sd card partition, taking care to preserve file attributes.

Edit fstab

In the not too old versions of Android, fstab file seems to be always located at /.
Files in / are stored in the BOOT partition (boot.img);
it's time to learn to edit the boot.img.
Here are two very helpful tutorials that will get you going:
HOWTO: Unpack, Edit, and Repack Boot Images
Android boot.img manipulation
a little hint:
Do edit the ramdisk in your Android device.
I spent three days in frustration trying to do so in my pc, I guess is a matter of "endianness".

When editing the ramdisk, do sort name-list(standard input) for cpio.
I spent three years in frustrating randomly recurring failures.

My fstab before:

/dev/block/mmcblk0p3        /efs            ext4        noatime,nosuid,nodev,journal_async_commit,errors=panic      wait
/dev/block/mmcblk0p9        /system         ext4        ro,noatime      wait
/dev/block/mmcblk0p8        /cache          ext4        noatime,nosuid,nodev,journal_async_commit,errors=panic      wait
/dev/block/mmcblk0p10       /preload        ext4        noatime,nosuid,nodev,journal_async_commit       wait
/dev/block/mmcblk0p12       /data           ext4        noatime,nosuid,nodev,noauto_da_alloc,journal_async_commit,errors=panic      wait,check,encryptable=footer

My fstab after:

/dev/block/mmcblk0p3        /efs            ext4        noatime,nosuid,nodev,journal_async_commit,errors=panic      wait
/dev/block/mmcblk1p9        /system         ext4        ro,noatime      wait
/dev/block/mmcblk1p8        /cache          ext4        noatime,nosuid,nodev,journal_async_commit,errors=panic      wait
/dev/block/mmcblk1p10       /preload        ext4        noatime,nosuid,nodev,journal_async_commit       wait
/dev/block/mmcblk1p12       /data           ext4        noatime,nosuid,nodev,noauto_da_alloc,journal_async_commit,errors=panic      wait,check,encryptable=footer

All I have changed is the block number (from 0 to 1).
I couldn't dare yet to relocate EFS, someone said that somehow you may brick the device playing around with that, still studying the subject; I do know that Android keeps writing EFS (I'm monitoring it).

Conclusions and further queries

This is how I relocated the most of my internal storage data to my external sd card.
Things are slightly sluggish, as expected, but Android seems to be in perfect working order;
I can always invest in a faster sd card in the future.
I did all of this with my Samsung Galaxy S III stock ROM, you will obviously have to adapt to your circumstances.
When I finally installed CyanogenMod 13 (we don't want stock firmware, do we!?) things were a bit different.
With a wiped /data, CM is spending some time at boot populating /data and at a certain point it just give up, reboot and goes to recovery mode.
After several attempts I gave up and relocated /system in internal memory, now everything is fine.
I do know that /system is mounted as read only, but I noticed that emmc lifespan is defined as amount of read/write cycles, maybe suggesting that, unlike hard drives, reading is as detrimental as writing.
If that's the case I'd be most grateful if someone could tell me why in CM I cannot successfully relocate /system.

  • What's the performance hit?
    – Jonathan
    Commented Apr 5, 2020 at 0:48
  • Hi @Jonathan, it's been a while now. As I said, things were pretty sluggish, it was getting into my nerves sometimes and I ended up reinstalling a fresh OS the traditional way. I was using a £5 Kingston 32GB Micro SD U1 HC I Class 10, maybe investing in a higher specs card would do. Let us know how it goes for you. By the way, my phone is about to turn 7 years old and, fingers crossed, it is still in good health 🥳
    – Claudio
    Commented Apr 6, 2020 at 8:45

@Claudio you have raised a very good concern. Having some embedded knowledge, I can give some idea about this:

When you switch ON a device, it is programmed to boot from specific memory location. This memory location is hardwired to internal memory.

Usually in demo embedded devices, we have a small switch which we can use to switch between different BOOT devices - it may be internal, external, even serial port.

But in production or commercial devices, this switch will be removed.

So, it is next to impossible to boot directly from external memory.

I wish some companies can provide a option(like switch) to boot from external memory even if internal memory goes wrong.

  • 1
    It'll never happen... Making loading and booting arbitrary code (2 separate things, both hard to achieve) so much easier is just wiping clean their past efforts of locking it down.
    – Andy Yan
    Commented Jun 7, 2017 at 7:48
  • Thank you @kumar for this useful piece of knowledge. Maybe it wasn't obvious in my description, but I never aimed to locate boot.img in a location other than the emmc
    – Claudio
    Commented Jun 8, 2017 at 9:38

I have been successfully able to boot from SD card on QMobile Z8 by:

  • Replicating eMMC partition table by partitioning SD card on a Ubuntu machine using parted and fdisk
  • Flashing factory firmware images to these newly created partitions using dd
  • Modifying fstab.qcom & init.tegra.rc files in kernel (boot.img) and recovery.fstab and uneventd.rc files in TWRP recovery to initiate mounting and booting from SDCard instead of internal memory

It was successful after some experiments. I think this method should be applicable to any device with similar configuration. However, files to be edited may vary from device to device.

If you want to put only apps' external data to SD card and not the whole partition, you can edit fstab in boot.img and storage list in framework-res.apk on Android 5 and older.


  • Does it necessary to edit recovery.fstab ? Commented Aug 7, 2023 at 22:44

You must log in to answer this question.

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