This patch increases the default size of the ram overlay from 512M to 1T.
I thought about adding an option in the same way as the prior num_loopdevs option, but I don't think that controlling the overlay size in this way is actually useful.
IMO the solution to controlling the ram overlay size, coincides with the solution to exposing the user to how much ram overlay they have available. The solution would be as follows-
1) take this patch, making the sparse ram overlay ridiculously large, i.e. 1T
2) instead of putting the ram overlay sparse file in the root of the initramfs tmpfs, create a tmpfs dedicated to it. Perhaps /mnt/.LiveOS/overlayfs (which then gets mount --move(d) to /sysroot/mnt/.LiveOS/overlayfs)
3) and then to support clean shutdown, modify /etc/rc.d/init.d/functions and halt such that they don't try to unmount that filesystem at shutdown. Code that does this was in my persistence/overlay patch submitted here a while back.
The result of this, is that "df -h /mnt/.LiveOS/overlayfs" will show you how much space is available there, and thus how much available for the read-write rootfs ram overlay.
You can then also remount that tmpfs with a different size at runtime, or based on a kernel argument, to increase/decrease at will (as opposed to the tmpfs default of half of existing ram)
NOTE: applying this patch will also suggest recompiling mkinitrd/nash with largefile support, to clear up the stat error on file-too-large which I believe is caused when the contents of the initramfs are deleted by nash/run-init/switchroot. (I think that is the fix).
This problem of not being able for users to detect how much ram space they have available for copy-on-write-rootfs has come up a few times on this list in the past, so I strongly suggest the above or some other solution to the problem.
-dmc