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.