I don't believe you'll be able to accomplish this. Windows is designed around the concept that the system partition is always available, and your experiment with the RAM overlay shows it's not designed for what you have in mind.
Instead, change the system partition. Use a non-hard-drive boot partition -- a LiveCD or USB key. You can certainly disable Windows access to non-system partitions, so moving the system partition off of hard drives will let you power down any attached hard drives.
Update:
After reviewing the materials on EWF, yes, this is possible.
I still think this is a case of not-what-it's-designed-to-do, but...
The EWF you used in WinXP came from Embedded XP. The Win-7 analogue is Windows Embedded Standard 2009, and does include the Enhanced Write Filter. I don't know if you'll be able to shoehorn EWF into Win-7, but you'll have better luck with the modern version than the old Embedded XP version.
It looks like you want "EWF RAM Reg mode", which places your EWF configuration data in the system Registry, and doesn't require a separate partition on the drive. The other modes (EWF Disk and EWF RAM modes) at minimum require a separate partition to operate.
You will want to review the techdoc on EWF Performance Considerations, particularly disabling last-access timestamps on NTFS, disabling System Restore, and changing the size of the pagefile (although it seems preferable to disable it, if possible).
Consider designing your own run-time image as your OS base. By doing so you can eliminate components of Win-7 that may be problematic in an embedded, static configuration (which is essentially what you're describing). You may also want to use a checked build, if available, at least until you get things working as expected.
Even this is, at best, educated guesswork. This method seems to be what a LiveCD uses to accomplish its magic, so you might have more luck looking into those. Even if a LiveCD is not your end-goal, the methods they use to build a system image may assist your endeavors. Best of luck!
OOM doesn't necessarily kill the process you think it will. Read about it here:
http://lwn.net/Articles/317814/
I suspect what is happening is that because chrome uses a different process for each page, it's confusing the OOM-killer's heuristics and other processes are being killed rather than the parent chrome process.
According to this, the OOM-killer likes to kill niced processes. So try setting chrome to a niceness of greater than 0.. might make it more of a target :-)
Best Answer
Quickly coded the "forced laptop mode" as io scheduler. Tested first in UML, then on my laptop even without a reboot.
http://vi-server.org/vi/0001-block-Introduce-hung-iosched.patch
When I issue
echo hung > /sys/block/sda/queue/scheduler, followed byhdparm -y /dev/sdathe hard drive stops and don't resumes.When I need to read something I just do "
echo cfq > /sys/block/sda/queue/scheduler.Also I can see what processes are wanting to cause spinup (they are D-sleeping). reiserfs and pdflush gets hung. Then syslogd.
To prevent sync attempts I temporarily disable syncs
echo 0 > /proc/sys/fs/sync-enable. It should be more or less safe given hard drive is already locked up. This is provided by http://vi-server.org/vi/0001-fs-Introduce-sync-enable-flag.patch.