Bug#510911: multipath-tools: bad side effects with FC devices

Guido Günther agx at sigxcpu.org
Fri Jan 9 17:46:01 UTC 2009


Hi Vince,
On Wed, Jan 07, 2009 at 09:40:22AM +1100, Vincent.McIntyre at csiro.au wrote:
[..snip..] 
> ok, then that's the problem. There are no multipathed devices on this
> system, so I was not expecting multipath-tools to 'do' anything.
> Is there something in the package documentation that would have explained
> this point to me? I may have missed it.
I don't think there is something like this (yet).

[..snip..]
> I expected multipath-tools to leave the device alone, or at least
> allow the system to mount and be able to access the data as before,
> since I had not 'told' the package about these devices.
> I had not configured /etc/multipath.conf, that file did not exist.
> Nor was there an /etc/default/multipath-tools.
This is all automatically being taken care off by
/etc/init.d/multipath-tools.

> On a system where we _do_ have multipathed storage, the devices are  
> referred to as /dev/mapper/mpath0p1, /dev/mapper/mpath1p1, etc.
You only get the mpath* devices if you use user_friendly_names=yes in
your multipath.conf, otherwise the WWID is used.

> So when I was looking at the /dev/mapper directory I was thinking that
> somehow some configuration had not completed, and that the files
> named using the WWN would be replaced by something 'friendlier'
> (for example the filesystem label, which is what was being used in
> the /etc/fstab, or /dev/mapper/mpath0).
See above.

> The behaviour of 'mount' and 'umount' was also extremely confusing.
> The device is not mounted and cannot be umounted but is 'busy'.
Because it's part of a multipath map.

> Why does 'lsof' not show what is keeping the device 'busy'?
Because there's no file descriptor involved.

> It might help if /dev/sdc1 was not created at all, since it
> can't be used to access the device. But I see in [2] that this
> is a decision taken by the kernel.
>
> The underlying bug here is probably my lack of understanding.
> But at the moment I don't see how to improve my understanding with
> the information available in the package. Some suggestions:
>
>  * if the package is able (at installation time) to detect devices that
>    it will start to manage at the next reboot, it would be helpful to
>    give a debconf warning about this and point people to /usr/share/doc.
>    I don't think there is such a warning now.
No there's no such warning and I don't want to add a pointer to avoid
unnecessary prompting. Pointing to
/usr/share/doc/multipath-tools/README.Debian in the package description
would be fine though.

>  * provide your paragraph in /usr/share/doc:
>      Once you use multipath you have to access multipathed devices via
>      /dev/mapper/<wwid> or via /dev/disk/by-id/.
>      For example, in /etc/fstab one could write:
>       /dev/mapper/<wwid>  /data/foo_1  ext3  defaults  0  0
We should better point people to /dev/disk/by-id/... since this way
mounting works with and without multipath.

>  * it would help to explain what the WWN-named files in /dev/mapper are.
>    I've had a go at a patch for this and the point above.
Thanks a lot for that. Would you mind extending README.Debian a bit
(instead of the FAQ) with the above suggestions and update the package
description to point to that file?

>
>  * alternatively, or as well, provide a default /etc/multipath.conf that
>    ignores/blacklists every device on the system, so multipath-tools won't
>    attempt to manage anything until the system owner takes a positive
>    action and configures the package.
I'd rather not. This would mean extra configuration for people that want
to use it.

> You may well ask 'wtf did you install the package in the first place?'.
> I was having a look-see to see what the package did when it was 
> installed, before trying it out on a system that does have multipathed 
> storage.
> I neglected to uninstall it again and was penalized heavily for this.
I think a pointer in the package description would have helped?

>
> You're doing a great job on this package, hope these comments help.
Thanks. I've picked up your fix to the FAQ's URL already and pushed that
out to:
  http://git.debian.org/?p=pkg-lvm/multipath-tools.git 
Cheers,
 -- Guido





More information about the pkg-lvm-maintainers mailing list