LVM data corruption

[Xen]

Robie Basak schreef op 23-01-2017 12:58:
> On Mon, Jan 23, 2017 at 12:42:37PM +0100, Xen wrote:
>> 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.
> 
> This won't happen unless someone interested in the problem files a bug.
> If you want to urge us to fix it in 16.04, you should file a bug.
> Otherwise, you should not expect that anything will happen at all.

Listen, I'm already ruining my work because I'm doing this for you. If 
you don't want to fix your own systems, that's fine with me.


> What sort of LVM?

Any LVM. My steps are detailed as they are.

> Exactly one LV in one VG on one PV? Or something else?

As told, it will start changing the _backing PV_ of any VG. So it 
doesn't matter how many PVs and how many LVs in the VG.

> What commands can a developer use to create this exactly? Please, save
> developers from having to look everything up and second guess exactly
> what you did.

dd if=/dev/sda of=/dev/sdb bs=1M

lvs


> The closer you can get to giving developers a script to
> run (inside a KVM, probably) to reproduce the problem, the more chance
> you have of getting some developer attention.

You are getting paid, I am not. I am losing money because I am doing 
this, okay.


> Which command? If one of many will do, please pick one and specify it
> exactly.

How more specific can I become than "any command"?

"lvs" will do just fine.


> Is there a command that will demonstrate the corruption immediately?

You will probably see the errors pop out if you are in a TTY.



> If you do not write a detailed bug report, then it is unlikely that
> anything will happen as a result of your report.

I am not your employee. You are probably getting money for this. I am 
not. I am losing time and money for you. Already. My report is 
completely detailed and it is as simple as it is.



> I can't say that this can easily be fixed in 16.04. A backport may be
> non-trivial, and bumping a major version of LVM seems also quite risky
> in terms of inadvertent changes in user-visible behaviour.

Great, something sensible.

It is not a major LVM version by the way. They haven't done any major 
versions in a long time.

If you mean changes in output used by scripts, I cannot tell. It is 
probably minimal and not something to excessively worry about. Also the 
person who has done 16.10 LVM2 would know about this, as that person 
should have known about these issues for 16.10 also. I consider it 
unlikely that bumping LVM2 from whatever to whatever will have visible 
consequences, but of course, that is for you to discern, not me.

I will not take any further responses on this.

Regards.