> From: James Heather <j.heather@surrey.ac.uk>
> > Is there a way to implement an artificial capacity limit that would
> > prevent processes from exhausting the overlay so that the reserve
> > might be used for recording the event and rebooting back to a safer
> > state?
>
> The easiest way is to play with the partition size (set in your
> kickstart file). There are two things that can stop a file being
> written: either the overlay is full, or the filesystem is full. If you
> set the partition size to a smaller value, you'll get filesystem errors,
> which are probably going to be less severe.

Thanks for that!  I was unaware of this aspect of the setup, but it makes sense.

> Of course, if you have a small partition size and a huge overlay, then
> most of your overlay will not ever be usable, so you want to play with
> the two things together. As a rough idea, the free space in your
> partition (after everything's been installed) should be a bit less than
> the overlay size.

Hmmm... presently I only specify the partition size in the kickstart.  I do not use the --overlay-size-mb <size> option with livecd-iso-to-disk.  I don't recall how I made that decision now, but I seem to recall there once being documentation stating that roughly half the RAM would be used for the overlay in this case, as a default.  IIRC, I went the "default" route (i.e., didn't specify --overlay-size-mb) because the devices vary considerably in the amount of RAM they have, from lowly 1GB Geode based PC/104 systems to 32GB Dell rackmount servers.

Do you have any advice how I should proceed given that variability and the desire to avoid the ungraceful failure case I've mentioned?  If I understand you correctly, I would want to limit my partition size such that the "free" space (i.e., partition size minus installed read-only image size) to be less than my overlay size, which I'm believing is half of all RAM.  Thus I'd probably want to use a fixed --overlay-size-mb value based on the smallest 1GB hardware.  That in turn would mean the larger devices are "artificially" crippled for file system COW capacity, but of course that extra RAM would be free for process.

Am I on the right track?
 
> There are potential pitfalls here, because free filesystem space doesn't
> quite equate with free overlay space. I don't know what happens if you
> boot up and delete a large file that was installed in the squashfs--it
> might increase the free space as far as the filesystem is concerned, but
> it obviously won't buy you any extra overlay space.

Good stuff to keep in mind.  For now, I think I'll worry about the above concerns and then come back to this once I've got the "simple" case down better.

Thanks!
--
John Florian