On Fri, 2005-02-04 at 14:06 +0000, Alasdair G Kergon wrote: > On Fri, Feb 04, 2005 at 10:49:15AM +0100, Magnus Nilsson wrote: > > Through pvmove'ing parts of the PV I've narrowed it down to PE #14858 of > > 38154 4MB PE's. > > > Is there any way of just skipping that last PE and let me repair the > > filesystem afterwards? Perhaps by vgcfgrestore'ing an edited backup, > > excluding the broken PV? > > > Firstly, pvmove --abort abandons a pvmove cleanly. > > Two ideas: > Use dmsetup directly to hide the problematic PE. > e.g. dmsetup table vg1-lvol1 to display the table, > Work out which sector(s) are the problem and replace them with > an 'error' line > > > Edit a (current) VG backup file to 'move' 1 extent elsewhere. > e.g. 1 segment containing the problematic extent turns into 3 segments > > Alasdair Thanks for the tips. I did try 'pvmove --abort' before mailing, but since the VG couldn't be found the pvmove couldn't be aborted. I tried using -P with pvmove, but the parameter wasn't recognised. I managed to fix the problem myself though. I thought that maybe the machine would behave differently if the disk was on a different controller, so I moved the faulty disk from the Promise TX2 controller to the motherboard. The machine still complained about the disk, but at least it didn't hard-lock. That allowed the final pvmove to go through, so I could vgreduce the PV. An fsck.ext3 discovered a couple of FS hickups on one of the 3 LV's, but nothing major. I hope that I will never have to use your ideas, ever. :) //Magnus _______________________________________________ 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/
