Changelog for 1.0.4 to 1.0.5 Driver ------ o Fixed pvmove lock bug in lvm_do_le_remap o use blk_ioctl() of blkpg.c in lvm_blk_ioctl in order to support BLKBSZSET and other general ioctls o Fixed OBO error on vg array access Tools ----- o vgscan - Workaround for minor metadata corruption bug in 1.1rc, for those downgrading. o vgcfgbackup - running vgcfgbackup with no VGs is not an error
The userspace components are not upgraded because they need to stay in sync with the kernel part.
we ship a rather modified lvm because the original one eats data alive ;( but that means we need modified tools too.
is this in ref to ext3's alleged misbehavior? https://lists.sistina.com/pipermail/linux-lvm/2002-July/011799.html yeah, the thread's talking about LVM2, of course, just curious
oh, and it's prob. worth checking the whole thread, of course, since Jens and Andrew got to chatting as well https://lists.sistina.com/pipermail/linux-lvm/2002-July/thread.html#11799
No, the LVM2/ext3 collision is over who owns the b_private field. Current LVM2 sources include a collision-avoidance for that, and once things are integrated in 2.5 there will be no problem since ext3 and LVM2 will be using separate data structures there (buffer_head versus bio structs.) The "eats data alive" bug in LVM is due to pvmove being a complex operation done partly in user-space (so it is deadlock-prone) and with incorrect locking and cache management (so it can corrupt data). We fixed that in our release and sent the patch upstream, but it is not merged in Sistina's LVM yet. I'll look into the 1.0.5 changes to see if there are bug-fixes we should merge into our packages.
LVM is deprecated; we are using the upstream dm packages in current Fedora kernels.