[linux-lvm] LVs corrupted after pvresize

Peter Larsen plarsen at CIBER.com
Fri Oct 17 05:23:50 UTC 2008


On Fri, 2008-10-17 at 06:05 +0200, Christian Völker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Yohoo!
> 
> |> I resized one of these RAID arrays for additional 250GB. After this was
> | Resizing a RAID-5 array is often not what you think, and doing so often
> | scrambles the data, depending on what RAID implementation you are using.
> I'm using a hardware RAID 3ware 9500S Controller. And this guy offers
> migration from RAID10 (4disks) to RAID5 (4disks, but with larger capacity).
> And I already did this task several times on these types of controllers.

That wasn't really the issue raised. Extending raids by adding new disks
doesn't do a balanced increase. In other words, you don't get a very
well functioning raid. Doing true raid migration is not straight
forward. So unless you fully restructure all data, you aren't getting
the performance you should be getting.

> | In any case, LVM was not your problem.
> This answer is too simple to be true.

Not really. Your approach was very poor.

> After the resize the partition and the PV were recognized correctly! 

Because at that time, the PVs were intact.

> So
> I'm pretty sure the migration was ok.

Again, you misunderstood Stuart's comment. He didn't say your RAID
migration didn't work. He said it wasn't optimal.

> But after the deletion of the partion, recreation and pvcreate

That's the error. There's a pvresize for a reason. You also need to use
the same UUID. Removing the PV makes your vg inconsistent and you've
basically @#$@# up LVM.

> everything went wrong. So for me it is obvious, LVM had an issue. But
> which one?

No - your use of LVM was wrong. Not LVM itself. 

--- 
Regards
    Peter Larsen

"Right now I'm having amnesia and deja vu at the same time."
		-- Steven Wright





More information about the linux-lvm mailing list