Bug 845319

Summary: stopping dmraid does not remove all nodes
Product: [openSUSE] openSUSE Tumbleweed Reporter: Arvin Schnell <aschnell>
Component: BasesystemAssignee: Coly Li <colyli>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: aschnell, hare, nfbrown
Version: 13.1 Beta 1   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Development Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Arvin Schnell 2013-10-10 14:36:32 UTC 
Stopping a dmraid does not remove all nodes/links:

g192:~ # ls -l /dev/mapper
ls: cannot access /dev/mapper: No such file or directory
g192:~ # dmraid -ay
RAID set "ddf1_foo" was activated
RAID set "ddf1_foo" was not activated
RAID set "ddf1_foop1" was activated
RAID set "ddf1_foop1" was not activated
RAID set "ddf1_foop2" was activated
RAID set "ddf1_foop2" was not activated
g192:~ # ls -l /dev/mapper
total 0
crw------- 1 root root  10, 236 Oct 10 14:34 control
brw-r----- 1 root disk 253,   0 Oct 10 14:34 ddf1_foo
brw-r----- 1 root disk 253,   1 Oct 10 14:34 ddf1_foop1
brw-r----- 1 root disk 253,   2 Oct 10 14:34 ddf1_foop2
lrwxrwxrwx 1 root root        7 Oct 10 14:34 ddf1_foo-part1 -> ../dm-3
lrwxrwxrwx 1 root root        7 Oct 10 14:34 ddf1_foo-part2 -> ../dm-4
g192:~ # dmraid -an
RAID set "ddf1_foop1" is not active
RAID set "ddf1_foop2" is not active
g192:~ # ls -l /dev/mapper
total 0
crw------- 1 root root  10, 236 Oct 10 14:34 control
brw-r----- 1 root disk 253,   0 Oct 10 14:34 ddf1_foo
lrwxrwxrwx 1 root root        7 Oct 10 14:34 ddf1_foo-part1 -> ../dm-3
lrwxrwxrwx 1 root root        7 Oct 10 14:34 ddf1_foo-part2 -> ../dm-4
Comment 1 Neil Brown 2013-11-04 22:24:11 UTC 
The -partX links are probable due to kpartx.

There seems to be a udev rule to run kpartx when dm devices are created, but not when they are removed.

We normally run dmraid with the "-p" option so that it doesn't create the partitions (leaving that to udev and kpartx).

What happens if you add "-p" to both the "-ay" and the "-an" ??

That should cause the "ddf_foop1" and "ddf_foop2" devices to not appear.
I don't know if it will affect the final removal for ddf1_foo.

Hannes:  Should used run kpartx also when the device is removed?
Comment 2 Neil Brown 2014-01-20 23:33:58 UTC 
Ping Hannes...
Can /etc/udev/rules.d/70-kpartx.rules  run
   /sbin/kpartx -d -p -part /dev/$kernel
or similar when a REMOVE event happens to clean up and partitions it has previously made?
Comment 3 Neil Brown 2014-02-06 04:03:27 UTC 
re-assigned to Hannes as I'm fairly sure it is a kpartx issue.
Comment 4 Hannes Reinecke 2015-05-28 09:14:32 UTC 
This looks like the companion issue of bug#930487.
'dmraid' has not been updated to use the device-mapper 'cookie' mechanism, hence it will instruct device-mappper to create device nodes under /dev/mapper on its own. This means we'll end up with _two_ sets of devices in /dev/mapper, the udev-created symlinks and the block device nodes create by device-mapper.
Comment 5 Hannes Reinecke 2015-05-28 09:20:22 UTC 
And actually, 'dmraid -p' should fail when there are partitions (or other device-mapper tables) on that device. The correct action is to remove the partitions (or other device-mapper devices) _first_ and then remove the dmraid device.

Much like you'd do with LVM; imagine you'd have a LVM setup on the dmraid device.
You surely do _not_ want dmraid to succeed here.

(For the same reason the udev rule wouldn't work, neither; we're only getting a 'remove' event if the device has been removed, which it can't, as it's being held busy by the devices stacked on top.)

So from my POV the system works as designed.