Repartir almacenamiento interno de SGH-I717

Siento no tener una respuesta definitiva para ti, pero tengo algo de información que puede guiarte en tu camino.

Nota: no todas las aplicaciones tienen que estar en la partición de 2GB, puedes usar varias aplicaciones Apps2SD, TitaniumBackup, o el gestor de aplicaciones integrado para mover ciertas aplicaciones a la partición de 10GB. Las aplicaciones que se ejecutan todo el tiempo (procesos de fondo, widgets, etc.) deben permanecer en la partición de 2 GB.

He tenido 3 dispositivos Android y creo recordar que una vez reparticioné uno de ellos, creo que era el GT-P1000 pasando de Android 1.x a 2.3. Estaba siguiendo una guía y no entendía bien lo que hacía, sólo seguía las instrucciones paso a paso... Sé que la repartición era necesaria porque hasta ese momento mis ROMs eran todas para un sistema de archivos basado en RFS y estaba haciendo la transición a ext4 para mejorar el rendimiento del kernel. Creo que también estaban reduciendo /system (ROM) para dar más espacio a /data (Apps).

En primer lugar, familiarízate con XDA. Todas las respuestas que he necesitado han estado ahí. Sé que todas las piezas necesarias para lograr esto están allí, sólo que tal vez no compilado en un solo hilo. He estado aprendiendo todas estas cosas durante los últimos 4 años, y tengo una experiencia profesional en programación y administración de sistemas durante más de 15 años antes de eso - puede tomar algún tiempo para que usted pueda recoger todo.

En segundo lugar, sí absolutamente esto es posible sólo que tal vez no sea práctico. Usted podría modificar un archivo PIT o hacerlo con fdisk a través de ADB mientras que en el modo de recuperación.

Hablas de redimensionar NTFS, pero ten en cuenta que el formato del sistema de archivos es independiente de tu tabla de particiones. En el mundo del PC puedes tener hasta 4 particiones en un disco duro, y puedes mezclar FAT16, FAT32, NTFS en cada partición todo lo que quieras. La primera partición primaria aparece como C:\Ny luego D:\Ny luego las particiones lógicas (Win9x y DOS sólo soportaban 1 partición primaria, el resto tenían que ser particiones extendidas con 1-4 particiones lógicas dentro de la extendida).

Redimensionar una partición no redimensiona un sistema de archivos. La mayoría de las herramientas de disco modernas realizan ambos pasos con un solo clic, pero siguen siendo dos pasos. Además, no todos los FS soportan el redimensionamiento, algunos sólo pueden crecer, y otros pueden reducir y crecer. Además, hay herramientas de terceros que pueden redimensionar formatos no redimensionables (PartitionMagic).

Como mencionas NTFS, supongo que eres un tipo de Windows, pero si estás familiarizado con Unix (y por lo tanto con Linux) será más fácil de seguir. Aquí hay una traducción de alto nivel:

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, ...

Las particiones están subordinadas a las unidades de disco:

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

Luego pones un Sistema de Archivos en tus particiones, y las montas.

Ventanas:

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

Además, la tabla de particiones tiene una pista que indica el tipo de sistema de archivos, pero no siempre coinciden. Sólo porque la tabla de particiones diga que /dev/hdb1 es del tipo 0x07, no significa que la tabla de archivos sea realmente NTFS. Un buen sistema operativo debería comparar los dos y negarse a montar el sistema de archivos, y una buena herramienta de formateo debería actualizar la tabla de particiones, pero no siempre... Samsung o Android son conocidos por asignar tipos de partición aparentemente arbitrarios para indicar la función y no el sistema de archivos. Estoy seguro de que hay una rima y la razón en alguna parte, pero no tengo idea de lo que es.

Android tiene muchas particiones, las 3 primeras son primarias, la 4ª es extendida y contiene hasta 30 particiones lógicas. Cada una tiene una función específica, y hay muchos FS diferentes, algunos conocidos y otros propietarios.

El almacenamiento incorporado de 16GB es equivalente a /dev/hda de x86 - pero lo llaman /dev/block/mmcblk0

La primera tarjeta SD es /dev/mmcblk1 y así sucesivamente. Las particiones de cada 'disco' reciben ...p1, ...p2, ...p3 y así sucesivamente.

Cada proveedor de productos y dispositivos tiene su propio esquema para distribuir las particiones.

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

El i717 utiliza el siguiente esquema, no sé lo que significa todo, pero la mayor parte sí (lo he sacado de la combinación de "df" y "fdisk -l /dev/block/mmcblk0" de Android y de "heimdall print-pit" de MacOS en modo descarga):

/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)

Así, tu partición de 2GB es /dev/block/mmcblk0p25 y tu partición de 10GB es /dev/block/mmcblk0p28.

Hacer lo que quieres preservando los datos no es realmente posible, pero ya he hecho algo similar en x86 de la siguiente manera:

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

En realidad, no hay herramientas disponibles para hacer todo eso. Un método más práctico:

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.

Básicamente estás ante un restablecimiento de fábrica, la ROM debería quedar intacta. Si tuviera que hacer esto lo haría:

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

Aquí está la tabla de particiones completa:

~ # 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

Iba a describir lo que podría hacer con fdisk, pero veo que la tabla de particiones existente deja espacios desiguales entre cada partición - esto me molesta porque no sé por qué. Tradicionalmente en los discos se creaba cada partición comenzando 1 sector después de la anterior. Por otra parte, los tamaños de las particiones siempre se alinean con los límites de los cilindros, así que tal vez cada nueva partición comienza en algún límite (¿múltiplos de potencias de 2?), incluso si la partición anterior no termina en uno. Los huecos son todos (múltiplos de 1024) más 1, pero hasta que no sepa cuál es la regla para hacer un hueco no tocaría las particiones... ¿Significa que puedo hacer la partición anterior 1024, 2048, 3192, 4096, ... bloques más grande? ¿Es que el sistema utiliza disimuladamente ese espacio en blanco para fines no documentados? quién sabe...

Nota al margen: Preguntas si instalar CyanogenMod ayudaría o si esto es más bajo. Las particiones son lo más bajo que se puede conseguir, luego están los cargadores de arranque, luego el kernel, luego la ROM (Cyanogen, ParanoidAndroid, etc), luego el espacio de usuario como /data, /sdcard y /external_sd. Arrancar en el modo de recuperación es como arrancar una imagen LiveCD de un sistema operativo sin disco donde todo el sistema se carga en la RAM. De esta forma puedes hacer lo que quieras en el disco duro: hacer una copia de seguridad, formatear, particionar, restaurar, redimensionar, diseccionar, clonar, etc.; luego, siempre y cuando lo vuelvas a juntar todo correctamente, puedes reiniciar en tu SO original.

En cuanto a por qué Samsung eligió este límite arbitrario de 2GB, es una cosa de compatibilidad con el pasado, cuando los chips de memoria de 2GB eran los más grandes que se podían conseguir, y en un dispositivo se tendrían 2 chips de 2GB. El primer chip tendría particiones para los cargadores de arranque, el kernel, Root(/), /usr y la ROM /system - y sería de LECTURA ÚNICA desde el sistema operativo en ejecución para evitar que los usuarios rompan la cosa; el segundo chip sería montado de LECTURA/ESCRITURA en /data para que los usuarios instalen aplicaciones y configuraciones. Ese era el Android básico que utilizaba el almacenamiento integrado. Si querías más espacio era a través de una tarjeta SD que ponías en una ranura, y ésta se montaba en /sdcard. Cuando los chips se hicieron más grandes y más baratos, Samsung mantuvo el diseño básico y básicamente te dio 12GB (10 utilizables) de almacenamiento interno presentándolo como /sdcard, luego añadieron el almacenamiento externo y crearon /external_sd. Esto causó mucha confusión, y algunas ROMs montaron la tarjeta SD externa como /sdcard y montaron los 12GB como algo más como /emmc. Saltar de una ROM a otra en aquel entonces era un dolor de cabeza si se cambiaba de un desarrollador a otro que seguía diferentes paradigmas. Hoy en día se ha estandarizado más con /storage/sdcard0, sdcard1, etc. y las aplicaciones se están diseñando con esto en mente, permitiendo a los usuarios elegir qué tarjeta SD utilizar en lugar de simplemente asumir que /sdcard o /emmc existen en la forma correcta.

Con todo, estoy de acuerdo en que 2GB es demasiado pequeño para /data, estoy constantemente moviendo aplicaciones a la SD e integrando las actualizaciones de las aplicaciones de Google en la ROM. Sin embargo, no creo que vaya a ser igual, y sé que no los combinaría en un gran /data y sólo tendría la SD externa como /sdcard - a la vieja usanza... Quizás 4 GB para /data y 8GB para /sdcard...

De todos modos, buena suerte.