On Fri, Apr 25, 2003 at 08:14:50AM -0500, Carey Jung wrote: > > > > Carey, > > > > which LVM/kernel versions are you using ? > > The error tells that the change for the mapping in the LVM driver fails. > > The latest RH rpm and smp kernel: > > # rpm -qa|grep lvm > lvm-1.0.3-4 > # cat /proc/version > Linux version 2.4.18-27.7.xsmp (bhcompile@stripples.devel.redhat.com) (gcc > version 2.96 20000731 (Red Hat Linux 7.3 2.96-112)) #1 SMP Fri Mar 14 > 05:52:30 EST 2003 > > > > > The mapping on disk (lvdisplay -Dv ...) doesn't get changed in that case. > > Must be a flaw in the ioctl error return handling, because it obviously > > got changed in the kernel as "lvdisplay -v " shows. > > That's Greek to me, :) The kernel hold the mapping table used at runtime and there's one on the disks to set it up. The one on disk is unlikely to have changed with the error you reported. > but something was seriously messed up with the PE > allocation or something, because I ended up trashing the LV after I sent > this message. I could read the entire partition just fine, so I thought I'd > copy it to another LV and then delete the original LV. So I created another > LV -- in the same VG as the original -- and started a big rsync copy from > source to destination LV. Halfway through it, rsync started complaining > that it couldn't find files that were on the source filesystem when it > started. When I snooped in the original LV, a bunch of directories had > disappeared! Bear in mind that I was just reading from this filesystem. Well, _if_ the mapping was bogus that will likely cause overwrites. No way to redo from start then :( > > My guess is that the PE allocation/mapping to LVs was messed up, so that > some PEs allocated to the new LV were actually mapped to the original LV, so > as I started writing to the new one, the system was overwriting files, etc > in the old LV. Several directories seemed to have been effectively 'mv'-ed > to the new LV. > > I then created yet another LV in a separate VG, rsync'ed both of the 1st two > LVs to it, recovered what was missing from a backup, and then lvremove'd the > first two. I'm also in the process of copying all the other LVs in that VG > to another VG, just because I'm not sure I can trust its integrity. > > By the way, is their some kind of tool one can run to do something analogous > to 'fsck' for VGs? Something that will walk through LVs and PEs and make > sure the VG is internally consistent? vgck(8) > > Thanks, > Carey > > > _______________________________________________ > linux-lvm mailing list > linux-lvm@sistina.com > http://lists.sistina.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ -- Regards, Heinz -- The LVM Guy -- *** Software bugs are stupid. Nevertheless it needs not so stupid people to solve them *** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Am Sonnenhang 11 56242 Marienrachdorf Germany Mauelshagen@Sistina.com +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _______________________________________________ linux-lvm mailing list linux-lvm@sistina.com http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
