[Oracleasm-users] Shifting from OCFS2 to ASM

[Joel Becker]

On Wed, Jun 17, 2009 at 09:33:11PM +0300, Karim Alkhayer wrote:
> Many thanks for the reply - actually, I did submit a few problems regarding
> OCFS2 1.2.1, but there weren't actually helpful thoughts regarding this
> fencing mechanism which followed by panic and node hang making the entire
> RAC unavailable.

	Fencing happens on ASM too.  ASM or ocfs2, it shouldn't make the
entire RAC unavailable.  I'm sorry that your issues didn't get resolved.

> One question here is how to make sure the LUNs are aligned for ASM? Do you
> have any guidelines on this? The LUNs are created using the SAN console and
> the OS recognize them as partitions once these LUNs are assigned to the
> node(s). There is no intervention with respect to the partitioning process
> on the OS level (each LUN is one partition). 

	I'm not sure what you mean here.  Storage arrays LUNs usually
present to the OS as whole disks, not partitions (eg 'sda' not 'sda1').

> As per the second point, the only reason I would prefer to use /dev/mapper/*
> is because dm changes if the assigned LUN list is altered, whilst
> /dev/mapper/* doesn't change. If ASMLib would really be an added value to
> the setup, then I will manage with dm.

	With ASMLib, you don't specify '/dev/dm-*' or '/dev/mapper/*'.
You label a disk, and ASMLib takes care of discovering the labels on the
disks itself.  In this fashion, the /dev path of the device can
change, but ASMLib will always find it.
	In fact, your /dev/mapper/* devices actually point to /dev/dm-*.
Check out the major,minor pair.  It's just a name.  With ASMLib, you
stop caring about the name and only worry about the label.  SCANORDER
just tells ASMLib which level of the multipathing to prefer.

> We've got AI64 SLES9 SP3; do you  recommend any OS upgrade prior installing
> anything? 

	Up to you guys.  SLES9 is older, but it all works.

> This scanning code seems to be interesting, I'd appreciate sharing the
> details.

	The ASMLib support tools scan all your disk devices to find ASM
disks.  This is how they map ASM disk labels to Linux /dev devices.  For
the most part, you don't have to care about this.  You just run
"oracleasm scandisks".  However, sometimes you want a little more
control over the scan.  The SCANORDER and SCANEXCLUDE variables provide
this at a basic level.  SCANORDER=dm is the most common one, making sure
that multipath devices are used instead of their component paths.
	However, the current scanning mechanism uses /proc/partitions
exclusively for its list of devices.  This means you have to use the
names in /proc/partitions for SCANORDER and SCANEXCLUDE.  I have some
beta code that allows the use of any name for a device, whether in
/proc/paritions, /sys/block, or /dev.  It just allows for more
flexibility in specifying SCANORDER and SCANEXCLUDE.

Joel


-- 

"Always give your best, never get discouraged, never be petty; always
 remember, others may hate you.  Those who hate you don't win unless
 you hate them.  And then you destroy yourself."
	- Richard M. Nixon

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127