[dm-devel] Multipath v. 0.4.7 trips over USB flash drive

[usvyatsky_ilya at emc.com]

Hi Mike,

Thanks for your suggestion. 
I have tried the upstream version of the multipath, but it seg. faulted.

Looks like it depends on an upstream version of dm.
This means massive upgrade that involves the kernel modules, so it'll
have to wait a bit.
I'll post an update here once I have it tested.

Thanks,
Ilya.


-----Original Message-----
From: dm-devel-bounces at redhat.com [mailto:dm-devel-bounces at redhat.com]
On Behalf Of Mike Anderson
Sent: Monday, November 19, 2007 4:33 PM
To: device-mapper development
Subject: Re: [dm-devel] Multipath v. 0.4.7 trips over USB flash drive

usvyatsky_ilya at emc.com <usvyatsky_ilya at emc.com> wrote:
> Hi there,
> 
> I am using DM MPIO for quite a while now and in general it works.
> Lately I encountered a problem with one of my boxes that is equipped
> with USB flash drive and is connected to a disk array.
> Namely, the flash drive has an empty bcdDevice entry, which translates
> into empty /sys/block/sdXX/device/rev file.
> As a result, the 'multipath -ll' command trips over this device and
> bails out without listing any array mpathXX devices.
> The devices are created in /dev/disk/by-name/ directory, so it's just
> the userland tool issue.
> 
> I've built debug version of multipath and found the following:
> 
> 1. The function sysfs_get_rev() (which is generated from macro
> declare_sysfs_get_str()) assumes that the rev has to have at least 2
> characters. Since in the case of my device this assumption is false,
the
> function returns 1.
> 2. The caller function is scsi_sysfs_pathinfo() and it returns 1 as
> well.
> 3. The caller function is sysfs_pathinfo(), which returns 1 as well.
> 4. The caller function is pathinfo(), which also returns 1.
> 5. The caller function is store_pathinfo(). Here the pathinfo is not
> stored and NULL is returned to the caller.
> 6. The caller is path_discover() that returns 1.
> 7. The caller is path_discovery() that returns non-zero result.
> 8. The caller is configure() that bails out on this result.
> 
> I have tried to work around this issue by blacklisting the device, but
> unfortunately the only blacklist check that is done prior to call to
> store_pathinfo() in the path_discover() is based on the devnode. 
> This means that effectively I cannot use this workaround since with
USB
> device I cannot guarantee that it will always be mapped to the same
> devnode.
> 
> I'd like to propose a couple of options for a fix for this issue:
> 
> 1. Re-implement sysfs_get_rev() in such a way that rev filed minimal
> length is no longer required. 
>    Please see attached a patch that is supposed to take care of this.
> 2. Re-implement pathinfo() to check whether vendor and/or product are
> blacklisted. 
>    This way non-compliant devices may be blacklisted based on vendor
> and/or product name.
> 
> I am not sure, which option is preferable, but I clearly need at least
> one of them in the product.
> 
> Your comments are greatly appreciated. 
> 
> Please note that my patch is against v. 0.4.7 of the multipath tool. 
> I realize that upstream may differ significantly, so if option (1)
makes
> sense I'll revalidate with the latest version and submit the patch if
> necessary.

The upstream version already removes the minimum size.

You should try the multipath-tools git tree version to see if it
addresses
your issue.

http://git.kernel.org/?p=linux/storage/multipath-tools/.git;a=summary

-andmike
--
Michael Anderson
andmike at linux.vnet.ibm.com

--
dm-devel mailing list
dm-devel at redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel