LVM 0.9.1_beta8 $Date: 2004/02/16 14:41:29 $ Known bugs in LVM 0.9.1_Beta8: - There is a very slight change that pvmove on a live system can corrupt your data. A pvmove on an offline (ie. not mounted) LV should be fine. - There is also a chance under high load that a live pvmove will deadlock your system. - Invalid snapshot metadata The Problem ----------- When removing a PV in the middle of a VG while snapshots are allocated on a PV further to the end of that VG, snapshot metadata gets invalid, because the PVs get renumbered and the COW exception table still contains the previous PV number(s). The Short Term Fix ------------------ Don't remove a PV from a VG when you have snapshots in it ;-) The Long Term Fix ----------------- Renumbering of the PVs will be avoided and the software will be capable to deal with the gaps in the internal PV number sequence. - Deadlocks when using snapshots The Problem ----------- When using 2.2 kernels and snapshots under *heavy* load people have been able to deadlock the system. This is caused by the lvm drivers indirectly allocating memory when servicing a snapshot copy-on-write exception, sometime this memory allocation causes the kflushd process to wake up, which in turn tries to write out the snapshot blocks and deadlocks on one of our semaphores. The Short Term Fix ------------------ LVM has therefore been altered (2.2 only) so that it preallocates buffer_head objects. Also changes have been made to fs/buffer.c to support preallocated buffer_heads, these changes are part of the automatically generated patch, they are not in Stephen Tweedies rawio patch. Systems running with these changes have run for many days under high load without problem. The Warning ----------- Although this problem has never been seen on 2.4 kernels, it may well be present, if you do experience deadlocks of this nature on 2.4 kernels please contact the linux-lvm@sistina.com mailing list ASAP. Other code outside our control such as low level device drivers may try to allocate memory which may cause a similar deadlock. The Long Term Fix ----------------- The long term plan to fix this problem is to create an in kernel thread (ksnapd) which deals with snapshot exceptions. This will have no issues with allocating memory and should give a big performance boost. - the sequence on a logical volume - format a filesystem with 4K blocksize - mount it - unmount it - reformat it with 1K blocksize - mount it again leads to a VFS error on some kernels, (2.2.19 and 2.4.3 work correctly) - there still seems to be a rare condition when vgscan(8) fails to find your VGs. Basically you only need to run vgscan if your disk configuration changed or your lost your /etc/lvmtab* entries.