Hi Vince, On Wed, Jan 07, 2009 at 09:40:22AM +1100, vincent.mcint...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
