I am having this exact problem with CentOS and have been banging my head
against it on and off for months.
I was able to mitigate it somewhat by doing something similar to what Moez
- In CentOS, a tempfs is a RAM-based emulated disk and is easy to mount up
with the right options
- On boot, my CentOS livecd creates the tempfs and moves all of "/root"'s
files over to it
- Then it sets the home directory for the root user as the tempfs
directory, so operations are performed out of it, instead.
This has helped reduce filesystem thrash on the overlay you mentioned
above, and it extends the life of the system but doesn't fix it completely
- kind of a bandaid.
You can track when the livecd is going to explode with "dmsetup status" and
watching the far right "number / number" on the live-rw mount. When the
smaller number meets the larger number, your filesystem remounts as read
I've been trying to figure out what these numbers represent, and posted this
but no one seems to know.
On Fri, Apr 17, 2015 at 10:36 AM, Moez Roy <moez.roy(a)gmail.com> wrote:
On Thu, Apr 16, 2015 at 4:13 PM, Moez Roy <moez.roy(a)gmail.com>
> Copying more than 500 MB crashes Fedora Live CD even though there is
> sufficient RAM.
> It doesn't matter how much RAM your system has, once you copy more
> than 500 MB you will get stuff like "Input/output error" or just plain
> crashes like "Segmentation fault".
> Why does this happen?
I think I figured out why this happens.
The file /usr/lib/dracut/modules.d/90dmsquash-live/dmsquash-live-root.sh
seems to create a 500MB overlay:
dd if=/dev/null of=/overlay bs=1024 count=1 seek=$((512*1024))
if [ -n "$setup" -a -n "$readonly_overlay" ]; then
RO_OVERLAY_LOOPDEV=$( losetup -f )
losetup $RO_OVERLAY_LOOPDEV /overlay
losetup $OVERLAY_LOOPDEV /overlay
Wouldn't it be more efficient if this was tmpfs instead?
This also affects installing applications in the live environment
where the installed size is more than 500MB.