Bug 524598

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):
livecd-tools-020.1-1.fc10.i386
lvm2-2.02.39-7.fc10.i386

How reproducible:
Very easy.

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.
  
Actual results:
Once RAM is exhausted the system becomes quite broken with most commands returning: seg. fault, i/o error, or command not found.

Expected results:
The file system should just become full and be no worse than a standard hard disk installation that has become full.

Additional info:
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.