LVM data corruption

[Xen]

Robie Basak schreef op 23-01-2017 12:05:
> On Sat, Jan 21, 2017 at 10:02:11AM +0100, Xen wrote:
>> The version of LVM that ships with 16.04 cannot handle duplicate 
>> UUIDs.
>> 
>> If you so much as DD a disk to another drive and run a single LVM 
>> command,
>> your running system will be ruined.
> 
> Is there a bug report on this somewhere, please, with detailed steps on
> how to reproduce?

I have no clue, but they knew about this issue.

David Teigland of LVM (Red Hat) wrote:

"The handling of duplicate PVs has been entirely redone in recent 
versions.
The problems you are having are well known and should now be fixed."

In reponse to my query and complaints ;-).

I then went on to change my sources.list to get for the moment 16.10 
"main" as well and upgraded LVM2.

At that point I was able to "import" the duplicate VG using 
"vgimportclone" which changes the UUIDs of the PV and VG and LVs, of the 
PV and LVs, I wanted to say, as well as that of the VG itself.

Which was another thing that didn't work. You are supposed to use 
vgimportclone after the import, but that even didn't work properly.

I mean after the duplication.

You're supposed to first do the "dd" and then run "vgimportclone" but 
both failed in the sense that...

Well, whatever.

You catch the drift.

Sorry for writing such a long message again. LVM team (Red Had) has now 
recognised, LVM2 has now recognised, LVM2 team has now recognised...

these issues and they are already fixed in newer versions, which is 
probably why they recognise it now after the fact because I had already 
asked back in the summer and got a negative reply then.

In any case the problems are apparently well known and have been fixed.

But the fixes are in 16.10 but not in 16.04 in that sense.

Perhaps you could say the intent of my message is to urge a newer 
version for 16.04 as well, but that is up to you. I just wanted to state 
the issues here.

I guess the reference here is: 
https://www.redhat.com/archives/linux-lvm/2017-January/msg00011.html

I did not then mention the data corruption (yet) so Teigland didn't 
actually respond to THAT. I mean to say that he responded to the issue 
of LVM randomly changing whatever "backing device" it uses.

Whatever backing PV it uses.

However he suggests that the handling of duplicates has been entirely 
redone.

Steps to reproduce would be simple:



1. DD your entire disk including partition table to another drive.

2. Run a single LVM command.

3. LVM will now -- sometimes -- -- often times -- start replacing the 
backing device of your earlier partitions.

4. If this actually happens (it might also choose to stick to the old, 
but maybe it always chooses the "higher" number (sdb over sda) so if you 
are backing up to a "later attached" drive this will probably happen) -- 
you will get the data corruption I mention.


But I don't see much the point of writing a detailed bug report, sorry. 
I also do not have the logs of the resulting fsck etc.

Also, since it is fixed, it would only be a bug against Ubuntu and not 
LVM.

It would probably (very very likely I think) not be possible to 
reproduce it with the newer versions (as long as it goes from 16.10, in 
that sense).

So the only thing you can do to ascertain this yourself is to:

1. Do it with 16.04
2. Do it with 16.10
3. Notice the difference, or

1. DD to a higher-numbered disk
2. Run LVM command
3. See if anything happens.

If it starts replacing the PV you are currently using, you are probably 
in trouble.