[Oracleasm-users] Shifting from OCFS2 to ASM

[Karim Alkhayer]

Hi Joel,

 

1.    In note 602952.1, it seems to be possible to create the ASMLIB disks
on /dev/mapper/*  

Example (same note): # /etc/init.d/oracleasm createdisk VOL1
/dev/mapper/mpath2p1

This example was given for RHEL5, is this same case with SLES9?

2.    I don't really understand the need to actually create a partition out
of a LUN in order to use it; can't I just use the entire disk immediately?
If no, why?

3.    Is a workaround to mark /dev/mapper/* as candidate disks? This should
be the best alternative for me; I assume "/dev/mapper/*" might work (perhaps
with or without ASMLib) 

4.    If your beta code is reliable, I'd love to check it out - thanks for
sharing the guidelines on how to use it!

 

Best regards,

Karim

 

-----Original Message-----
From: Joel Becker [mailto:Joel.Becker at oracle.com] 
Sent: Thursday, June 18, 2009 2:28 AM
To: Karim Alkhayer
Cc: oracleasm-users at oss.oracle.com
Subject: Re: [Oracleasm-users] Shifting from OCFS2 to ASM

 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/oracleasm-users/attachments/20090619/15b31ac2/attachment.html