Bug 471400

Summary:	Error while handling RAID1 devices.
Product:	Red Hat Enterprise Linux 5	Reporter:	Joel Andres Granados <jgranado>
Component:	dmraid	Assignee:	Heinz Mauelshagen <heinzm>
Status:	CLOSED WORKSFORME	QA Contact:	Cluster QE <mspqa-list>
Severity:	urgent	Docs Contact:
Priority:	medium
Version:	5.3	CC:	agk, christophe.varoqui, coughlan, ddumas, dwysocha, edamato, egoggin, emcnabb, hdegoede, heinzm, jbrassow, jgranado, junichi.nomura, krzysztof.wojcik, kueda, lmb, mbroz, prockai, rpacheco, syeghiay, tao, tranlan
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-11-17 17:08:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Comment 1 Joel Andres Granados 2008-11-13 14:55:25 UTC

I did a quick check for device-mapper bugs and did not find anything related to this issue.  Sorry if it is duped.

To reproduce just execute `dmraid -ay` on a system that has RAID1. On my system it fails with the following errors:

<snip>
device-mapper: table: 253:0: mirror: Wrong number of mirror arguments
device-mapper: ioctl: error adding target to table.
</snip>

This python script also reproduces the same error (same errors as above):
<snip>
#!/usr/bin/python

import block
rs = block.getRaidSets([])
rs0 = rs[0]
rs0.activate(mknod=True)
</snip>

This breaks installation to RAID1 devices.  This is the reason I put all the flags on ?.

Comment 5 Heinz Mauelshagen 2008-11-13 16:17:46 UTC

Joel,

you need kernel 123.el5 and dmraid-1.0.0.rc13-16.el5

Comment 6 Joel Andres Granados 2008-11-13 16:40:35 UTC

Everyone:

I'm Terribly sorry about this,  This *does* have to do with the fact that the
brno mirror is out of sync.  I have made tests with current kernel and dmraid
and everything works fine.

Again sorry for the noise.

Comment 7 Alasdair Kergon 2008-11-13 16:49:45 UTC

I disagree.

What if someone installs the update, then has some kernel problem so wants to reboot using the previous (working) 5.2 kernel without downgrading all their packages?

This is ABI breakage that needs mitigating - a blocker.

LVM2 should not suffer from this because in conjunction with libdevmapper it detects what version of the kernel module it is and supplies the appropriate arguments.

dmraid should do the same.

Comment 9 Alasdair Kergon 2008-11-13 18:06:11 UTC

But is this actually a kernel issue requiring a kernel update as requested above - or just a userspace regression introduced after 5.2 and fixed in 1.0.0.rc13-15 ?

Comment 10 Heinz Mauelshagen 2008-11-14 09:12:41 UTC

Alasdair,

with respect to your comment #7: dmraid-1.0.0.rc13-16.el5 work on both actual and older RHEL5 kernels, there's no KABI breakage. in dmraid-1.0.0.rc13-14.el5 I mistakenly introduced a regression because of the different KABIs in upstream/RHEL with respect to mirror error handling activation, which has been fixed in dmraid-1.0.0.rc13-16.el5 recommended in comment #5. The 123.el5 kernel provides the extended RAID0/1 status output and needs testing to avoid any related regressions with dmraid, lvm2, ...

I think that addresses you question in comment #9 as well.

Comment 13 Tom Coughlan 2008-11-17 17:08:19 UTC

Closing this, based on comment 10 (this problem was introduced early in 5.3, and is now fixed in 5.3. dmraid remains compatible with earlier RHEL 5 kernels), and comment 12 (earlier RHEL 5 kernels have block_on_error, so dmraid remains compatible). Feel free to followup with additional questions and re-open if necessary.