From: James Heather <j.heather(a)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
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
Of course, if you have a small partition size and a huge overlay,
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
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