I've come across some variations of this question, but I'm unable to find a definitive solution.

I have a Samsung Galaxy Note SGH-I717, currently running Android 4.1.2. The phone is advertised as 16GB, of which 1.97GB is "device memory" and 10.84GB is "USB storage".

How can I increase the "device memory" partition at the expense of the "USB storage" partition?

My understanding is that I will need a PIT file, but I'm not sure where I can get this. Ideally, I would want the internal storage divided into 2 equal partitions.

2GB for app storage is not nearly enough, and I don't know why Samsung imposes such arbitrary limits.

I'm open to other suggestions as well. Would installing Cyanogenmod allow for a modification of these partitions, or is this controlled at an even lower layer?


  • The partition are indipendent of the os, so installing cyanogen will not help.
    – Fabiusp98
    Dec 27, 2014 at 23:44
  • @Fabiusp98 Thanks for the confirmation. I was leaning towards that. So do you know a way of doing this? I don't understand why this is so difficult, since an NTFS filesystem could be partitioned fairly easily.
    – TechCzar
    Dec 29, 2014 at 0:46

1 Answer 1


Sorry I don't have a final answer for you, but I have some info that can lead you on your way.

Sidebar: not all apps have to sit in the 2GB partition, you can use various Apps2SD apps, TitaniumBackup, or the built in app manager to move certain apps to the 10GB partition. Apps that run all the time (background processes, widgets, etc) should stay on the 2GB partition.

I've owned 3 android devices and I seem to recall repartitioning one of them once upon a time, I think it was GT-P1000 going from android 1.x to 2.3. I was following a guide and didn't fully understand what I was doing, just following step by step instructions... I know that repartitioning was needed because up until that point my ROMs were all for an RFS based filesystem and I was making the transition to ext4 for improved kernel performance. I think they were also shrinking /system (ROM) to give more space to /data (Apps).

Firstly, get familiar with XDA. Every answer I've ever needed has been in there. I know all the pieces required for you to accomplish this are in there, just maybe not compiled into a single thread. I've been learning all this stuff over the past 4 years, and have a professional background in programming and system administration for 15+ years prior to that - it may take some time for you to pick it all up.

Secondly, yes absolutely this is possible, just maybe not practical. You could either modify a PIT file or do it with fdisk through ADB while in recovery mode.

You talk about resizing NTFS, but be aware the filesystem format is independent of your partition table. In the PC world you can have up to 4 partitions on a hard drive, and you can mix FAT16, FAT32, NTFS on each partition all you like. The first primary partition comes up as C:\ then D:\ then logical partitions (Win9x & DOS only supported 1 primary partition, the rest had to be extended partitions with 1-4 logical partitions within the extended).

Resizing a partition does not resize a filesystem. Most modern disk tools do both steps for you with a single click, but it's still two steps. Also not all FS support resizing, some can only grow, and some can shrink & grow. Then again there are 3rd party tools that can resize non-resizable formats (PartitionMagic).

Because you mention NTFS I'm presuming you're a windows guy, but if you're familiar with Unix (and thus Linux) it will be easier to follow along. Here's a high level translation:

HardDisk1 (primary master) on a PC will show up as /dev/hda in Linux x86.
HardDisk2 (primary slave) is /dev/hdb
HD3 (secondary master) is /dev/hdc
HD4 (secondary slave) is /dev/hdd
SCSI, SATA and USB disks might be /dev/sda, /dev/sdb, ...

Partitions are subordinate to the drives:

HD1, Part1 = /dev/hda1
HD1, Part2 = /dev/hda2
HD1, Part3 = /dev/hda3
HD2, Part1 = /dev/hdb1
HD2, Part2 = /dev/hdb2

Then you put a File System on your partitions, and mount them.


HD1,P1::NTFS, mounted as C:\
HD2,P1::ExFAT, mounted as D:\

Linux x86:

/dev/hda1::ext3 mounted as /
/dev/hda2::JFS mounted as /usr
/dev/hdb1::ExFAT, mounted as /data

Also, the partition table has a hint indicating what filesystem type is laid out, but they don't always match. Just because the partition table says /dev/hdb1 is type 0x07, doesn't mean the file table is actually NTFS. A good OS should compare the two and refuse to mount the filesystem, and a good formatting tool should update the partition table, but not always... Samsung or Android is notorious for assigning seemingly arbitrary partition types to indicate function rather than filesystem. I'm sure there's a rhyme and reason somewhere but I have no idea what it is.

Android has many partitions, the first 3 are primary, the 4th is extended and contains up to 30 logical partitions. Each has a specific function, and there are many different FS, some known and some proprietary.

The 16GB built-in storage is equivilant to x86's /dev/hda - but they call it /dev/block/mmcblk0

The first SD card is /dev/mmcblk1 and so on. Partitions on each 'disk' get ...p1, ...p2, ...p3 and so on.

Each product vendor and device has its own scheme for laying out partitions.

See http://forum.xda-developers.com/showthread.php?t=1959445

The i717 uses the following scheme, I don't know what everything means, but most of it I do (I got this from combining android's "df" & "fdisk -l /dev/block/mmcblk0" and from MacOS "heimdall print-pit" while in download mode):

/dev/block/mmcblk0 <-- entire 16GB 'disk'
/dev/block/mmcblk0boot0 - ???
/dev/block/mmcblk0boot1 - ???
/dev/block/mmcblk0p1 - SMD_HDR - Primary boot loader
/dev/block/mmcblk0p2 - SBL1 - Secondary boot loader #1, your flash counter sits in here
/dev/block/mmcblk0p3 - SBL2
/dev/block/mmcblk0p4 - Extended Partition, container for the following logical partitions
/dev/block/mmcblk0p5 - RPM
/dev/block/mmcblk0p6 - SBL3
/dev/block/mmcblk0p7 - ABOOT
/dev/block/mmcblk0p8 - BOOT
/dev/block/mmcblk0p9 - TZ
/dev/block/mmcblk0p10 - SSD
/dev/block/mmcblk0p11 - PIT
/dev/block/mmcblk0p12 - PARAM
/dev/block/mmcblk0p13 - MODEM - 100MB /firmware vfat (baseband modem part 1)
/dev/block/mmcblk0p14 - MSM_ST1
/dev/block/mmcblk0p15 - MSM_ST2
/dev/block/mmcblk0p16 - MSM_FSG
/dev/block/mmcblk0p17 - 100MB /system/etc/firmware/misc_mdm vfat (modem part 2)
/dev/block/mmcblk0p18 - M9K_EFS1
/dev/block/mmcblk0p19 - M9K_EFS2
/dev/block/mmcblk0p20 - M9K_FSG
/dev/block/mmcblk0p21 - DEVENC - 10MB /efs ext4 - individual info like IMEI and Encryption
/dev/block/mmcblk0p22 - RECOVERY - 10MB  - Recovery, ClockWorkMod or TWRP
/dev/block/mmcblk0p23 - FOTA
/dev/block/mmcblk0p24 - SYSTEM - 1GB /system ext4
/dev/block/mmcblk0p25 - USERDATA - 2GB /data ext4
/dev/block/mmcblk0p26 - CACHE - 300 MB /cache 
/dev/block/mmcblk0p27 - TOMBSTONES - crash dump area?
/dev/block/mmcblk0p28 - UMS 10GB /sdcard user's playground (usually a vold virtual device)

So, your 2GB partition is /dev/block/mmcblk0p25 and your 10GB partition is /dev/block/mmcblk0p28.

To do what you want while preserving data is not really possible, but I've done similar on x86 before as follows:

first you have to shrink the filesystem on /dev/block/mmcblk0p28,
then shrink the partition,
then move the partition to the end of the disk,
then move p27 to end just before p28 starts,
move p26 to butt up against p27,
grow partition p25 to fill the empty space in front on p26,
then extended filesystem on p25 to fill the partition...

In reality, there aren't any readily available tools to do all that. A more practical method:

1 You'll have to back up the contents of p25, p26, p27 and p28 to external SD,
2 rebuild the partition table with the new boundaries,
3 create new filesystems on each,
4 then restore data onto each.

You're basically looking at a factory reset, the ROM should stay intact. If I were to do this I would:

0 insert a brand new 32GB sd card into the note
1 boot to recovery
2 connect with adb shell
3 mount /dev/block/mmcblk1p1 to /external_sd
4 mount /dev/block/mmcblk0p25 to /data
5 mount /dev/block/mmcblk0p28 to /sdcard
6 tar /data to /external_sd/data.tar
7 tar /sdcard to /external_sd/sdcard.tar
8 unmount /data and /sdcard
9 use fdisk to rebuild partitions p25, p26, p27 & p28 where p25 is bigger, p26 & p27 are moved and p28 is smaller
10 make new filesystems on all four p25-p28
11 mount /data and /sdcard again
12 untar /external_sd/data.tar to /data
13 untar /external_sd/sdcard.tar to /sdcard
14 pray
15 reboot

Here's the full partition table:

~ # fdisk -ul /dev/block/mmcblk0

Disk /dev/block/mmcblk0: 15.7 GB, 15758000128 bytes
1 heads, 16 sectors/track, 1923584 cylinders, total 30777344 sectors
Units = sectors of 1 * 512 = 512 bytes

              Device Boot      Start         End      Blocks  Id System
/dev/block/mmcblk0p1               1      204800      102400  92 Unknown
  Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2   *      204801      205800         500  4d Unknown
  Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3          205801      208800        1500  51 Unknown
  Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4          208801    30777343    15284271+  5 Extended
  Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5          212992      213991         500  47 Unknown
/dev/block/mmcblk0p6          221184      225279        2048  45 Unknown
/dev/block/mmcblk0p7          229376      234375        2500  4c Unknown
/dev/block/mmcblk0p8          237568      258047       10240  48 Unknown
/dev/block/mmcblk0p9          262144      263143         500  46 Unknown
/dev/block/mmcblk0p10         270336      271335         500  5d Unknown
/dev/block/mmcblk0p11         278528      279527         500  91 Unknown
/dev/block/mmcblk0p12         286720      307199       10240  93 Unknown
/dev/block/mmcblk0p13         311296      511999      100352   c Win95 FAT32 (LBA)
/dev/block/mmcblk0p14         516096      522239        3072  4a Unknown
/dev/block/mmcblk0p15         524288      530431        3072  4b Unknown
/dev/block/mmcblk0p16         532480      538623        3072  58 Unknown
/dev/block/mmcblk0p17         540672      741375      100352  8f Unknown
/dev/block/mmcblk0p18         745472      751615        3072  59 Unknown
/dev/block/mmcblk0p19         753664      759807        3072  5a Unknown
/dev/block/mmcblk0p20         761856      767999        3072  5b Unknown
/dev/block/mmcblk0p21         770048      790527       10240  ab Darwin boot
/dev/block/mmcblk0p22         794624      815103       10240  60 Unknown
/dev/block/mmcblk0p23         819200      839679       10240  94 Unknown
/dev/block/mmcblk0p24         843776     2940927     1048576  a5 FreeBSD
/dev/block/mmcblk0p25        2940928     7139327     2099200  a6 OpenBSD
/dev/block/mmcblk0p26        7143424     7761919      309248  a8 Darwin UFS
/dev/block/mmcblk0p27        7766016     8030207      132096  a9 NetBSD
/dev/block/mmcblk0p28        8036352    30777343    11370496  90 Unknown

I was going to describe what you might do with fdisk, but I see that the existing partition table leaves unequal gaps between each partition - this bothers me because I don't know why. Traditionally on disk you would create each partition starting 1 sector after the previous. Then again your partition sizes would always align with cylinder boundaries so perhaps each new partition is starting on some boundary (multiples of powers of 2?) even if the previous partition didn't end on one??? The gaps are all (multiples of 1024) plus 1, but until I know what the rule is for making a gap I would not touch the partitions... Does it mean I can make the previous partition 1024, 2048, 3192, 4096, ... blocks bigger? Is the system sneakily using that blank space for undocumented purposes? who knows...

Sidebar: You ask if installing CyanogenMod would help or if this is lower. Partitions is about as low as you can get, then there's the boot loaders, then the kernel, then the ROM (Cyanogen, ParanoidAndroid, etc), then user space like /data, /sdcard and /external_sd. Booting into recovery mode is kind of like booting a LiveCD image of a diskless OS where the entire system is loaded into RAM. That way you can do whatever you want to hard drive: backup, format, partition, restore, resize, dissect, clone, etc; then as long as you put it all back together correctly you can reboot back into your original OS.

As for why Samsung chose this arbitrary 2GB limit, it's a backward compatibility thing from back when 2GB memory chips was the biggest you could get, and in a device you would have 2 x 2GB chips. 1st chip would have partitions for boot loaders, kernel, root(/), /usr and the /system ROM - and be READ-ONLY from the running OS to prevent users from breaking the thing; the 2nd chip would be mounted READ/WRITE on /data for users to install apps & settings. That was basic android using built-in storage. If you wanted more space it was through an SD card you put in a slot, and this was mounted on /sdcard. When chips got bigger & cheaper Samsung stuck with the basic design and basically gave you 12GB (10 usable) of internal storage presenting it as /sdcard, then they added external storage and made up /external_sd. This caused lots of confusion, and some ROMs mounted the external SD card as /sdcard and mounted the 12GB as something else like /emmc. Jumping ROMs back then was a pain if you were swapping between Devs who followed different paradigms. Today it's become more standardized with /storage/sdcard0, sdcard1, etc and apps are being designed with this in mind, letting users pick which SD card to use rather just assuming /sdcard or /emmc exist in the right form.

All in all, I agree 2GB is too small for /data, I'm constantly moving apps to SD and integrating google app updates back into the ROM. I don't think I'd go equal though, and I know I wouldn't combine them into one big /data and just have external SD as /sdcard - the old way... Maybe 4 GB for /data and 8GB for /sdcard...

Anyways, good luck.

You must log in to answer this question.

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