Multipath command output - Help with understanding output

Dan Track dan.track at gmail.com
Tue Oct 13 18:03:20 UTC 2009


On Tue, Oct 13, 2009 at 7:01 PM, Dan Track <dan.track at gmail.com> wrote:
> On Tue, Oct 13, 2009 at 6:45 PM, Bryn M. Reeves <bmr at redhat.com> wrote:
>> On Tue, 2009-10-13 at 18:23 +0100, Dan Track wrote:
>>> I've already got the following /dev/mapper/mpath0 and
>>> /dev/mpath/3600c0ff000d7ba4f4575b24a01000000. Can you tell me how I
>>> can reload the config and end up with /dev/mapper/san1?
>>
>> That's a little bit strange; normally you'd expect the /dev/mpath
>> entries to follow the same naming as is used in /dev/mapper.
>>
>> That said, the symlinks in /dev/mpath are nothing but trouble and it is
>> strongly advised that you don't use them for anything. The main problem
>> is that they can at times get out-of-sync with the device-mapper status.
>> This can lead to a range of problems such as failed booting (since the
>> correct device names don't exist at the point they should in the boot
>> process) to data corruption when a stale symlink ends up pointing to the
>> wrong multipath device.
>>
>> This happens because the device nodes in /dev/mapper are managed by
>> libdevmapper and so are updated in-sync with the state of the devices in
>> the kernel but the symlinks are managed in userspace by udev and so
>> there can be delays between the device-mapper's state changing and the
>> corresponding symlinks getting updated.
>>
>>> Also when running pvcreate should I run
>>>
>>> pvcreate /dev/mapper/mpath0
>>
>> Always prefer the names in /dev/mapper when working with multipath
>> devices.
>>
>> Regards,
>> Bryn.
>>
> Many many thanks Bryn. I owe you one.
>
> Thanks
> Dan
>
Bryn,

Is there any chance you could help with the my other mail I sent
titled: "Testing Device Failure".

I basically want to test this setup.

Thanks
Dan




More information about the users mailing list