[Nook Color Android Development] steven676:
Nope, none of them do (sigh, bad bad BN). That said, the extended partition is really just a container for the logical partitions -- its alignment isn't all that important.

Is there a reason to expand /cache? As I understand it, now that dalvik.vm.dexopt-data-only is the default both on AOSP and CM, /cache is used solely for keeping stuff for the recovery. In that case, the only lower bound on /cache's size is that it needs to be able to fit an OTA package, and in that case the current /cache is already nearly 2x as large as it needs to be.

What fdisk is this? Be aware that this fdisk seems to treat +768M as 7.68 x 10^8 bytes (HD manufacturers' units -- 1 MB = 1000 KB = 10^6 bytes), but our 4MB eraseblocks are 4 x 2^20 bytes ("real" units -- 1 MB = 1024 KB = 2^20 bytes = 1048576 bytes). To align the partitions correctly while minimizing wasted space, we either need to get fdisk to work in "real" KB/MB/GB units, or (probably safer) work entirely in sector counts.

Also, note that there's an off-by-one issue here that might be wasting quite a bit of space -- a partition that begins on sector 909312 and ends on sector 2409312 (inclusive) is 1,500,001 sectors long (note the "750000+" notation in the count of 1024-byte disk blocks -- it's there because this partition is actually 750000.5 1K blocks long), which means that if sector 2409312 represented an eraseblock boundary we'd now have to skip the rest of the eraseblock (8191 sectors) to get the next partition to align to the start of an eraseblock. Assuming the system will let you fit partitions back-to-back without space in between to begin with, you want the last sector of the first partition to be an odd number (eraseblock start - 1), which allows the next partition to begin on the eraseblock boundary without needing to pad for alignment purposes.

Bottom line: it's probably safest to work entirely in 512-byte sectors to avoid unit confusion.

One other question: is this a SEM08G or M8G2FA eMMC part (look in /sys/class/block/mmcblk0/device/name if you're not sure)?

encore's somewhat unusual in the embedded world in that our internal storage is partitioned exactly as a PC hard drive is -- using an on-disk MS-DOS-style partition table which we can freely modify. As such, no kernel-level changes are necessary -- we can use existing, well-tested tools to repartition the device.

Randall's normally on the mark, but I can't lie here -- I'm really not sure what's so complicated about "tar xf file.tar": simple, easy-to-remember, sensible ("x" -- extract, "f" -- file to operate on), and something "real" *nix people use often enough that it's embedded deep into muscle memory ...

Now, if he'd said something about cpio ... :)

No -- the point of /data/media is that it's no longer a separate partition from /data, which allows the two to share disk space (no more need to decide how much space to allocate to app data and how much to pictures/video/content). /data must support the traditional POSIX file permissions, so it can't be vfat (wellllll ... you could do umsdos or posixovl, but why would you want to?); Google's solution to providing the traditional permissionless semantics for /sdcard therefore involves a FUSE daemon which overlays /data/media and essentially strips permissions.

Well, all of /cache, for one -- there's no point in including it in the backup in the first place. Other than that, everything should be backed up, I think -- the idea is to create a near-exact copy of the old data in the new partition layout. (I suppose we could skip /data/dalvik-cache if we really wanted, but I'm not sure it's worth it -- it's likely faster to backup and restore that data than it is to regenerate it on the next boot.)

We could, but whether we should depends entirely on how fast we expect the SD card we're storing to is going to be. We can't predict compression ratios -- if /emmc is mostly ebooks, it'll compress really well, but if it's all video, it'll barely compress at all -- so the only way to give a safe estimate of disk space required for the backup is to assume no compression at all. (Besides, it's not as if 8GB or larger microSD cards are expensive or hard to find these days ...) Basically, then, the question is whether the time saved by doing less I/O to the SD card is more or less than the extra time it takes the CPU to compress the data; I suspect that if compression is going to come out ahead, it's going to involve a fast algorithm like gzip, not one with high compression ratios like LZMA. Benchmarks welcome :)