Hi guys. Just want to notify about troubles with using dm-multipath with scsi_transport_fc (a very common combination).
The SCSI transport copes with loss of remote rports by removing the device node. However dm-multipath isn't designed to cope with this, and keeps the internal kernel structures open, preventing them from being removed completely. When the lost rport is revived, the re-addition of the device-node fails with an -EEXIST error. See http://thread.gmane.org/gmane.linux.scsi/36123 for more information.
In addition the device removal causes multipathd to remove paths from the dm map, causing the map to be suspended (also discussed in the post above). This breaks queue_if_no path due to lacking use of no_flush (as I understand it). This is supposedly fixed by multipath-tools 0.4.8, but Ubuntu has yet to upgrade to this version unfortunately.
The other enterprise distros has worked around these problems by adding a patch that allows the user to disable the devnode removal on rport loss. This patch was submitted upstream here http://thread.gmane.org/gmane.linux.scsi/25318 but never made it into the upstream kernels. I get the impression the SCSI people believes they're doing the Right Thing (probably true) and take the hard stance that the dm team is the ones that should fix their end instead, and forcing this by not providing a workaround in the SCSI layer. This of course hurts users, which is probably why SuSE and Red Hat have added the workaround anyway.
I ask you to at least consider following RH and SuSE on this one for the next LTS release (unless dm-multipath is fixed of course).
Regards
Tore Anderson
Hi Tore,
Thank you for your report and helping to make Ubuntu better. Beginning with the Hardy release, the kernel source package naming convention has changed from linux-source-2.6.24 to just linux. Therefore, I'm reassigning to the 'linux' package.
I'll also assign this request to the kernel team. However, note that It is a lot of extra work for the Ubuntu kernel team to maintain out of tree patches. As you probably already know, they typically prefer upstream acceptance before considering to maintain community patches locally. I'll leave it to their discretion regarding the maintenance of this patch in Ubuntu. Thanks!