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.
Windows:
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.
