> From: James Heather <email@example.com>
> > 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
> > 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
> 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,
> most of your overlay will not ever be usable, so you want to play
> the two things together. As a rough idea, the free space in your
> partition (after everything's been installed) should be a bit less
> 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
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
> 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,
> 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.