Hooray! I think I've found a definitive clue to a crash during lvremove of a snapshot. I have a reliably repeatable failure test and a workaround that seems to be passing. Here's the regression test: -------------------------- 1. arrange to have some continuous i/o on an lvm volume I do it with a simple shell loop that copies a 1GB file to another name and then back (essentially: 'while :;do cp abcd wxyz;cp wxyz abcd;done') 2. while that's running, start a snapshot create/remove loop Such as 'while :;do lvcreate -snSnap -L10G LVorigin; lvremove -f /dev/VG/Snap;done My experience is that a system crash always occurs upon executing the lvremove call. The first one! (On my most recent experiments, the system is locking hard, although earlier I was able to see a kcopyd oops and the keyboard scollback worked.) Here's the workaround --------------------- In the snap-cycle test surround the lvremove command with suspend/resume dmsetup suspend VG-LVorigin lvremove -f /dev/VGorigin/Snap dmsetup resume VG-LVorigin I am currently testing this workaround on a patched 2.6.14-1.1637_FC4 kernel (using 4 patches suggested by agk on Tue, 15 Nov 2005 22:33:58 +0000) <excerpt from that prior message> --------------------------------- > > The kcopyd.c BUG at line 145 is triggered by the first lvremove > > following start of the i/o (copy loop). Try some kernel patches. http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/ in particular these four: dm-snapshot-bio_list-fix.patch dm-snapshot-metadata-reading-separation.patch dm-snapshot-load-metadata-on-creation.patch dm-ioctl-reduce-pf-memalloc-usage.patch </excerpt> ==> BUT I suspect the lvremove problem is independent of those patches, as I was getting the same symptom before putting in the suspend/resume. I thought I had tried suspend/resume previously and found that they were unnecessary because the create automatically performed a suspend/resume -- so my current workaround is the result of a desperation-experiment of applying the suspend/resume wrapper ONLY to the lvremove step. ==> SO MAYBE this current success points to a bug in the lvremove code, eh? I plan on repeating my test on a vanilla kernel. In the meantime, I hope someone can look at the lvremove code (agk?..). Regards, ..jim _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
