[Barnes & Noble Nook Tablet] PMikeP:
How about a swap?

First, thanks for an excellent post. I'm a noob and hope to use your detailed instructions for a little project I'm trying on my Nook HD+.

I want to make use of dead space in one of our partitions and use it for swap.

But it's going to take a week for me to hack through it. (If nothing else, I've got to get ADB running.) Whereas I bet you can do it in 10 minutes. So can I entice you into writing a similar, small tutorial over in the HD+ forum (in my thread) about creating a swap file in the /system partition? I'm told the Nook Tablet and the HD+ file systems are basically the same. (Except we have 10 partitions. You have 11.) So you've already done the work.

Here's the deal: I've learned we have a /factory partition that's used by B&N automagically to recover (to the stock OS) if there are any problems during boot.

But I'm running CM 10.2.1 on my HD+. And TWRP. That means that the factory.zip file won't do me any good. First, with a custom recovery, factory.zip won't get called at all. Second, even if I flash the stock recovery back in, calling the factory.zip will only cause a bootloop with CM if triggered. (I'd probably have to wipe first to get factory to reflash properly.)

So, why keep the factory.zip at all? I've already stored it on my computer for safe keeping if I ever need it in the future. As it stands now, it's 443 MB of wasted eMMC that can be used for something else.

So how about using it as a swap file? Wouldn't that give us almost 1.5 G of effective RAM? Faster memory than swap on an ext SD card too.

This assumes that I wouldn't burn out the eMMC with swap. But we "swap" to eMMC with zRAM anyway.

But you'd know best.

Hmmm... could you give me the code for making a swap file in /data? (That's p10 in the HD+.) That should show me if there's any performance to be gained by this crazy idea.

UPDATE: Nevermind. Found it in xda. (Amazing what's on the web. Am trying 500 MB in /data now.)

I've read that /factory also contains unique backups from /rom. (like devconf) So I pulled those out of a factory.img and made a new 1MB image file with those in it. I've read that they might be called if there's a problem with /rom. So I'd want to keep them.

Now I'm planning to use your instructions to destroy my /factory partition, recreate a 1MB partition in its place, and dd my new 1MB image back into that.

Then I would make a dd image of my /system partition, p8. After that, I would destroy the /system partition, recreate a new partition that's 443 MB larger than OEM, and restore the system.img there. (Or maybe 442 MB larger to play it safe, so I don't bump into p9.)

Then I would make a 440 MB swap file. (You know, I don't even know the arcane Unix commands to do that. I've read them, but I don't know how to mount it at eMMC p8.)

[I read just now that /system is read only. If true in CM, then would have to change it to read-write.]

I was originally going to move everything down from p7 and create a new p11 at the high end of unallocated space to make a swap partition. But if nothing else, that will never get TRIM'd by the OS. But /system does get trimmed. (Or, at least, Lagfix will trim /system.) So hopefully, no lag build up.

I suppose TWRP and CWM backups would be larger, backing up the swap file each time. But that's okay.

I know dinking with partitions is fraught with danger for a mere performance gain. (Per the warnings in your post above.) But you did it. :)

If I hose the /factory partition, I don't think I'd even know. I hope not to hose the /system partition if I follow your instructions. But with a TWRP backup of /system as well as a system.img, hopefully I'd be able to get things back if I did. Those are the only two partitions I'd be hacking.

In the worst case, I could make a bootable SD with factory on it and start all over again. (That assumes that a factory install recreates p's 8-10.)

I'm willing to take the chance it if there's an upside.

Whaddya think? Intriguing? Or dumb idea?