Re: Multipath or Oracle RAC ASM issue?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 19, 2008 at 12:43:55AM +0100, Bryn M. Reeves wrote:
> Joel Becker wrote:
> > 	This works as you expect.  The names in
> > /dev/(mapper|mpath)/mpathX should be identical on each server.
> 
> It's often best to avoid the symlinks in /dev/mpath. Depending on your
> version of udev they may get seriously out of sync with device creation,

	Oh, that stinks.  Not having dealt with them much, I was unaware
of that.
 
> multipath/multipathd manage the mpathX names directly (creating them via
> libdevmapper). It's udev that adds the symlinks (possible at some later
> time).

	Thanks for the correction.

> > 	You don't.  You don't care.  If you want a /dev name, you use
> > the mpathX name that you know maps correctly.  Since you are using
> > ASMLib, you don't worry about that either.  The LANDx names are read by
> > ASMLib to ensure ASM sees the correct devices no matter what /dev name
> > they have.
> 
> It is important here to make sure that the aliases are synchronised. You
> can do this by syncing the bindings file between the hosts or by using
> explicit alias { /*...*/ } entries in multipath.conf.

	I assume you're talking about synchronizing the mpathX aliases.
the LANDx names were selected by the user via ASMLib, and not part of
the usual multipathd/udev/dm stuff.

> > 	That's not the issue, and I'm sorry Oracle support gave you the
> > wrong answer.  You can createdisk against any name that's correct
> > (/dev/dm-X, /dev/mapper/mpathX, /dev/mpath/mpathX).  scandisks doesn't
> > even need a name - it just needs the correct order in your case.
> 
> Yeah, that's unfortunate. The dm-N nodes are really internal
> device-mapper names and the general advice is to always prefer the
> /dev/mapper names. Recent distributions tend to have udev rules that
> ignore these devices & avoid creating the /dev/dm-N nodes completely.

	I wish they would leave the /dev/dm-N nodes alone.
/dev/mapper/* doesn't show up in /proc/partitions, and thus is
impossible to scan simply for.  A future ASMLib toolset will have new
scan code that walks /sys/block and can handle devices that don't show
up in /proc/partitions, but current releases need /dev/dm-X nodes.  When
people run into that, I have them uncomment that rule in udev.

Joel

-- 

"Anything that is too stupid to be spoken is sung."  
        - Voltaire

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@xxxxxxxxxx
Phone: (650) 506-8127

--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster

[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux