Description of problem:
The use of LVM snapshots (COW) to provide a writable file system is clever, but has a downside that prevents systems from running those images for long periods of time without a necessary reboot. Eventually the snapshot will exhaust all available resources despite the normal logrotate, etc. because the COW tends not to reuse blocks much, if at all.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot a system running a image created by livecd-tools.
2. Let run a long time (depends on available RAM) or accelerate the process by frequently writing to the syslog for example. The same basic problem can be seen with "dd if=/dev/zero of=/tmp/foo bs=1M count=NNN" where NNN is the number of MB free minus a few. Erase the file and notice that df shows no reclamation of the space. Overwriting the file leads to the same results.
Once RAM is exhausted the system becomes quite broken with most commands returning: seg. fault, i/o error, or command not found.
The file system should just become full and be no worse than a standard hard disk installation that has become full.
The livecd-tools package is very enticing for creating embedded systems around PC/104 hardware, but this issue makes it infeasible as it currently exists. I will be reworking our systems to boot with /tmp and /var mounted over tmpfs, which does achieve the expected results (provided all other parts are read-only). It would be really nice if livecd-tools did this by default.
*** This bug has been marked as a duplicate of bug 465725 ***