Bug 584688

Summary: multipathd didn't check information with dm-multipath
Product: [Fedora] Fedora Reporter: Jozef <jozef.janec>
Component: device-mapper-multipathAssignee: Ben Marzinski <bmarzins>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 14CC: agk, bmarzins, dwysocha, fdinitto, heinzm, lvm-team, msnitzer, prockai
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 17:18:59 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:

Description Jozef 2010-04-22 08:01:21 UTC
Description of problem: When the mpath devices are cerated and we are using frendly names, and I remove/ or change destination of bindigns file, multipathd cerate new one which is different from currect status in dm-multipath , and result is corupted filesystem


Version-Release number of selected component (if applicable):


How reproducible:
simulate
edit bindigs file and swap lun IDS, and restart multipathd, I think it should check the currect status amd wrote some error that there are differences and not activate the new cofnig or the lines


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
multipathd activate the paths by new bindigs file and he swaped the pointers to PVs in device mapper



> mkdir /etc/multipath
> vi  /etc/multipath.conf
> 
> I have added bindings_file "/etc/multipath/bindings"
> 
> And restarted multipathd to create the config on the new location.
> 
> I got the same issue when I have removed the old and restarted 
> multipathd to cerate the bind file again, by actual status
> 
> /etc/init.d/multipathd restart 
> Shutting down multipathd                                              done 
> Starting multipathd                                                   done 
> 
> ls -l  /etc/multipath/bindings -rw------- 1 root root 815 Apr 20 03:06 
> /etc/multipath/bindings
> 
> Now I have compared the old with new (old is ok)
> 
> diff /etc/multipath/bindings /var/lib/multipath/bindings
> 8,22c8,22 &lt;
> mpatha 3600508b40006b6180000e00006d60000 mpathb 
> 3600508b40006b6180000e00006d30000 mpathc 
> 3600508b40006b6180000e00006450000 mpathd 
> 3600508b40006b6180000e00006400000 mpathe 
> 3600508b40006b6180000e000063a0000 mpathf 
> 3600508b40006b6180000e00005430000 mpathg 
> 3600508b40006b6180000e000028e0000 mpathh 
> 3600508b40006b6180000e00001dc0000 mpathi 
> 3600508b40006b6180000e00001a30000 mpathj 
> 3600508b40006b6180000e000019d0000 mpathk 
> 3600508b40006b6180000e000013f0000 mpathl 
> 3600508b40006b6180000e00001390000 mpathm 
> 3600508b40006b6180000e00001330000 mpathn 
> 3600508b40006b6180000e000012d0000 mpatho 
> 3600508b40006b6180000e00001270000
> ---
> mpatha 3600508b40006b6180000e00005430000 mpathb 
> 3600508b40006b6180000e000028e0000 mpathc 
> 3600508b40006b6180000e00001dc0000 mpathd 
> 3600508b40006b6180000e00001a30000 mpathe 
> 3600508b40006b6180000e000019d0000 mpathf 
> 3600508b40006b6180000e000013f0000 mpathg 
> 3600508b40006b6180000e00001390000 mpathh 
> 3600508b40006b6180000e00001330000 mpathi 
> 3600508b40006b6180000e000012d0000 mpathj 
> 3600508b40006b6180000e00001270000 mpathk 
> 3600508b40006b6180000e000063a0000 mpathl 
> 3600508b40006b6180000e00006400000 mpathm 
> 3600508b40006b6180000e00006450000 mpathn 
> 3600508b40006b6180000e00006d30000 mpatho 
> 3600508b40006b6180000e00006d60000
> 
> And when I have checked the actual status for example
> 
> multipath -ll mpatha
> mpatha (3600508b40006b6180000e00005430000) dm-8 HP,HSV210
> [size=15G][features=1 queue_if_no_path][hwhandler=0] \_ round-robin 0 
> [prio=200][active] \_ 3:0:9:15 sddp 71:112 [active][ready] \_ 3:0:8:15 
> sddn 71:80  [active][ready] \_ 1:0:7:15 sddf 70:208 [active][ready] \_
> 1:0:6:15 sddd 70:176 [active][ready] \_ round-robin 0 
> [prio=40][enabled] \_ 3:0:7:15 sddl 71:48  [active][ready] \_ 3:0:3:15 
> sddj 71:16  [active][ready] \_ 1:0:8:15 sddh 70:240 [active][ready] \_
> 1:0:0:15 sddb 70:144 [active][ready]
> 
> grep 3600508b40006b6180000e00005430000 /etc/multipath/bindings mpathf 
> 3600508b40006b6180000e00005430000
> 
> I don't know why the multipathd don't read the actual configuration, 
> it creates new one, and the big problem is that after this it activate 
> this new one. There is no check if the bindings file is ok for actual status.
> 
> The result is that the multipathd activate for exaple lun with ID 
> 3600508b40006b6180000e00005430000  under device mpathf in lvm structure.
> And under mpatha other lun. And this makes that that if something 
> start write or work with filesystem which is configured on mpatha 
> device now it will be directed to wrong lun wrong place, and it will corupt whole filesystem.
> 
> I alerady saw on many servers that multipathd generated file bindings 
> but it changed order of lun ids
> 
>  multipath -ll | grep dm- | sort -nk1
> mpatha (3600508b40006b6180000e00005430000) dm-13 HP,HSV210 mpathb
> (3600508b40006b6180000e000028e0000) dm-14 HP,HSV210 mpathc
> (3600508b40006b6180000e00001dc0000) dm-15 HP,HSV210 mpathd
> (3600508b40006b6180000e00001a30000) dm-16 HP,HSV210 mpathe
> (3600508b40006b6180000e000019d0000) dm-17 HP,HSV210 mpathf
> (3600508b40006b6180000e000013f0000) dm-18 HP,HSV210 mpathg
> (3600508b40006b6180000e00001390000) dm-19 HP,HSV210 mpathh
> (3600508b40006b6180000e00001330000) dm-20 HP,HSV210 mpathi
> (3600508b40006b6180000e000012d0000) dm-21 HP,HSV210 mpathj
> (3600508b40006b6180000e00001270000) dm-22 HP,HSV210 mpathk
> (3600508b40006b6180000e00006d60000) dm-8 HP,HSV210 mpathl
> (3600508b40006b6180000e00006d30000) dm-9 HP,HSV210 mpathm
> (3600508b40006b6180000e00006450000) dm-10 HP,HSV210 mpathn
> (3600508b40006b6180000e00006400000) dm-11 HP,HSV210 mpatho
> (3600508b40006b6180000e000063a0000) dm-12 HP,HSV210
> 
> I have one ida
> 
> 1. this status is because modprobe dm-multipath loaded the actual 
> bindings file 2. the multipath isn't checking actual status from dm-multipath but may be the order
>    from other scsi command the real order visible for server 3. but I 
> think there should be some check and don't allow activate this configuration
>    until the configuration from dm-multipath is different because the 
> result is 100% fs corupted

Comment 1 Ben Marzinski 2010-04-26 16:12:11 UTC
What version of fedora are you using.  Multipath doesn't support the "bindings_file" configuration option anymore.  That was a RHEL5 hack until we could move the bindings file to the proper location for everybody.  In Fedora Rawhide, multipath and multipathd should always use /etc/multipath/bindings, and there should be now way to change it.

Comment 2 Bug Zapper 2010-07-30 11:26:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Fedora End Of Life 2012-08-16 17:19:01 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping