[Droid Eris Android Development] bftb0:
Here's my current space usage summary:

# df /system /data /cache
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mtdblock3 174080 103240 70840 59% /system
/dev/block/mtdblock5 163328 118560 44768 73% /data
/dev/block/mtdblock4 133120 38432 94688 29% /cache

This is a CELBFroyo 4.1 Eris, 40+ apps, no movement of anything to the SD card. I don't accumulate E-mails, SMS/MMS, or call logs. Nuke 'em every so often an move along.

So, judging from this single snapshot - I could stand to give up space in both /system and /cache to get a litte more (or a lot more!) /data. But I'm honestly not hurting for anything - I still have 44 MB free in /data.

Those three partitions (system-cache-data) are contiguous in the Eris:

http://xdaforums.com/attachment.php?attachmentid=431912&d=1288689612

The methods described in the URLs you provided work for the Eris, but (obviously) the offsets and partition sizes need to be adjusted correctly to account for the Eris flash memory layout. The from-the-factory Flash memory layout can be found here

I have unpacked (split_bootimg.pl) and repacked (mkbootimg) Amon_RA's recovery, injecting up to 14 (yes, the Eris has 14 partitions) partition definitions in the kernel command line simultaneously, and everything boots up just fine (and /system, /data, and /cache) all mount just fine doing that.

e.g.

[ 2.845275] allocated dma buffer at ffa47000, dma_addr 2482b000
[ 2.845489] read CFG0 = aa5400c0, CFG1 = 8744a
[ 2.845520] CFG0 = e85408c0, CFG1 = 8744a
[ 2.845550] CFG0: cw/page=3 ud_sz=516 ecc_sz=10 spare_sz=0 num_addr_cycles=5
[ 2.845642] NAND_READ_ID = 5501bcec
[ 2.845855] status: c03120
[ 2.845855] nandid: 5501bcec maker ec device bc
[ 2.845947] CFG0: cw/page=3 ud_sz=512 ecc_sz=10 spare_sz=4
[ 2.846038] DEV_CMD1: f00f3000
[ 2.846130] <6>NAND_EBI2_ECC_BUF_CFG: 1ff
[ 2.846160] flash_id: 5501bcec size 20000000
[ 2.846282] 14 cmdlinepart partitions found on MTD device msm_nand
[ 2.846313] Creating 14 MTD partitions on "msm_nand":
[ 2.846343] 0x00001ff60000-0x000020000000 : "misc"
[ 2.848449] 0x000002c60000-0x000003160000 : "recovery"
[ 2.854888] 0x000003160000-0x0000033e0000 : "boot"
[ 2.859344] 0x0000033e0000-0x00000dde0000 : "system"
[ 3.054595] 0x00000dde0000-0x000015fe0000 : "cache"
[ 3.214691] 0x000015fe0000-0x00001ff60000 : "userdata"
[ 3.393402] 0x000000000000-0x000002980000 : "radio"
[ 3.440734] 0x000002980000-0x0000029a0000 : "gap"
[ 3.441955] 0x0000029a0000-0x000002a60000 : "hboot"
[ 3.443969] 0x000002a60000-0x000002aa0000 : "misc3"
[ 3.445556] 0x000002aa0000-0x000002ae0000 : "mfg"
[ 3.447021] 0x000002ae0000-0x000002ba0000 : "sp1"
[ 3.449096] 0x000002ba0000-0x000002c00000 : "misc2"
[ 3.450714] 0x000002c00000-0x000002c60000 : "mfg2"

The arguments to "mkbootimg" for the "standard" layout of the Eris can be found here - all you need to do is modify the sizes and offsets appropriately to get the desired sizes.

[SIZE=+4]BUT! ...[/SIZE] ( <- that'a a big but! )

...there is a problem that you need to be aware of.

This hack does not alter the actual partition table stored in Flash Memory. So, you could re-package a custom recovery (Amon_RA or ClockworkMod) so that it had your new (desired) sizes for /system, /cache, /data, and flash it to your recovery, and that would allow you to flash things to the newly sized partitions...

[SIZE=+2]...but you would also need to do this for the boot image of every ROM you wanted to use![/SIZE]

That is to say, you need to provide the same kernel command line to every bootable image on the phone - both the recovery partition image, and the boot partition image.

It would be a much easier go if the actual partition table was written, rather than overriding the "real" partition table with kernel command line arguments - then you would be free to use whatever recovery image and whatever ROM you wanted without hassle; doing it this way requires that for every ROM you might want to try, you:

1 unpack the ROM

2 split_bootimg.pl on the boot.img

3 mkbootimg (with the mtdparts=msm_nand: kernel command line arguments )

4 re-zip the ROM

5 re-sign the ROM.

This could all be automated with some scripting, but it is still a bit of a hassle for the average user.

Maybe to gauge relevancy we could have folks post up their results for

adb shell df /system /cache /data

to get a sense of how often people are really bumping in to memory problems.

bftb0