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.
*** This bug has been marked as a duplicate of bug 465725 ***