<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1576741085;
mso-list-type:hybrid;
mso-list-template-ids:-1899433852 -280334728 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:11.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoPlainText><span style='font-family:"Arial","sans-serif"'>Hi Joel,<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-family:"Arial","sans-serif"'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-family:"Arial","sans-serif"'><span style='mso-list:Ignore'>1.<span
style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span
style='font-family:"Arial","sans-serif"'>In note 602952.1, it seems to be
possible to </span><span style='font-size:10.5pt;font-family:"Arial","sans-serif"'>create
the ASMLIB disks on /dev/mapper/* <o:p></o:p></span></p>
<p class=MsoListParagraph><span style='font-size:10.5pt;font-family:"Arial","sans-serif"'>Example
(same note): </span><span style='font-family:"Arial","sans-serif"'>#
/etc/init.d/oracleasm createdisk VOL1 /dev/mapper/mpath2p1<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='font-family:"Arial","sans-serif"'>This example
was given for RHEL5, is this same case with SLES9?<o:p></o:p></span></p>
<p class=MsoPlainText style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Arial","sans-serif"'><span
style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-family:"Arial","sans-serif"'>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?<o:p></o:p></span></p>
<p class=MsoPlainText style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Arial","sans-serif"'><span
style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-family:"Arial","sans-serif"'>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) <o:p></o:p></span></p>
<p class=MsoPlainText style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Arial","sans-serif"'><span
style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-family:"Arial","sans-serif"'>If
your beta code is reliable, I’d love to check it out – thanks for
sharing the guidelines on how to use it!<o:p></o:p></span></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><span style='font-family:"Arial","sans-serif"'>Best regards,<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-family:"Arial","sans-serif"'>Karim<o:p></o:p></span></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>-----Original Message-----<br>
From: Joel Becker [mailto:Joel.Becker@oracle.com] <br>
Sent: Thursday, June 18, 2009 2:28 AM<br>
To: Karim Alkhayer<br>
Cc: oracleasm-users@oss.oracle.com<br>
Subject: Re: [Oracleasm-users] Shifting from OCFS2 to ASM<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>On Wed, Jun 17, 2009 at 09:33:11PM +0300, Karim Alkhayer
wrote:<o:p></o:p></p>
<p class=MsoPlainText>> Many thanks for the reply - actually, I did submit a
few problems regarding<o:p></o:p></p>
<p class=MsoPlainText>> OCFS2 1.2.1, but there weren't actually helpful
thoughts regarding this<o:p></o:p></p>
<p class=MsoPlainText>> fencing mechanism which followed by panic and node
hang making the entire<o:p></o:p></p>
<p class=MsoPlainText>> RAC unavailable.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> Fencing happens on ASM
too. ASM or ocfs2, it shouldn't make the<o:p></o:p></p>
<p class=MsoPlainText>entire RAC unavailable. I'm sorry that your issues
didn't get resolved.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>> One question here is how to make sure the LUNs are
aligned for ASM? Do you<o:p></o:p></p>
<p class=MsoPlainText>> have any guidelines on this? The LUNs are created
using the SAN console and<o:p></o:p></p>
<p class=MsoPlainText>> the OS recognize them as partitions once these LUNs
are assigned to the<o:p></o:p></p>
<p class=MsoPlainText>> node(s). There is no intervention with respect to
the partitioning process<o:p></o:p></p>
<p class=MsoPlainText>> on the OS level (each LUN is one partition). <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> I'm not sure what you mean
here. Storage arrays LUNs usually<o:p></o:p></p>
<p class=MsoPlainText>present to the OS as whole disks, not partitions (eg
'sda' not 'sda1').<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>> As per the second point, the only reason I would
prefer to use /dev/mapper/*<o:p></o:p></p>
<p class=MsoPlainText>> is because dm changes if the assigned LUN list is
altered, whilst<o:p></o:p></p>
<p class=MsoPlainText>> /dev/mapper/* doesn't change. If ASMLib would really
be an added value to<o:p></o:p></p>
<p class=MsoPlainText>> the setup, then I will manage with dm.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> With ASMLib, you don't
specify '/dev/dm-*' or '/dev/mapper/*'.<o:p></o:p></p>
<p class=MsoPlainText>You label a disk, and ASMLib takes care of discovering
the labels on the<o:p></o:p></p>
<p class=MsoPlainText>disks itself. In this fashion, the /dev path of the
device can<o:p></o:p></p>
<p class=MsoPlainText>change, but ASMLib will always find it.<o:p></o:p></p>
<p class=MsoPlainText> In fact, your
/dev/mapper/* devices actually point to /dev/dm-*.<o:p></o:p></p>
<p class=MsoPlainText>Check out the major,minor pair. It's just a
name. With ASMLib, you<o:p></o:p></p>
<p class=MsoPlainText>stop caring about the name and only worry about the
label. SCANORDER<o:p></o:p></p>
<p class=MsoPlainText>just tells ASMLib which level of the multipathing to
prefer.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>> We've got AI64 SLES9 SP3; do you recommend any
OS upgrade prior installing<o:p></o:p></p>
<p class=MsoPlainText>> anything? <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> Up to you guys.
SLES9 is older, but it all works.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>> This scanning code seems to be interesting, I'd
appreciate sharing the<o:p></o:p></p>
<p class=MsoPlainText>> details.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText> The ASMLib support tools
scan all your disk devices to find ASM<o:p></o:p></p>
<p class=MsoPlainText>disks. This is how they map ASM disk labels to
Linux /dev devices. For<o:p></o:p></p>
<p class=MsoPlainText>the most part, you don't have to care about this.
You just run<o:p></o:p></p>
<p class=MsoPlainText>"oracleasm scandisks". However, sometimes
you want a little more<o:p></o:p></p>
<p class=MsoPlainText>control over the scan. The SCANORDER and
SCANEXCLUDE variables provide<o:p></o:p></p>
<p class=MsoPlainText>this at a basic level. SCANORDER=dm is the most
common one, making sure<o:p></o:p></p>
<p class=MsoPlainText>that multipath devices are used instead of their
component paths.<o:p></o:p></p>
<p class=MsoPlainText> However, the current
scanning mechanism uses /proc/partitions<o:p></o:p></p>
<p class=MsoPlainText>exclusively for its list of devices. This means you
have to use the<o:p></o:p></p>
<p class=MsoPlainText>names in /proc/partitions for SCANORDER and
SCANEXCLUDE. I have some<o:p></o:p></p>
<p class=MsoPlainText>beta code that allows the use of any name for a device,
whether in<o:p></o:p></p>
<p class=MsoPlainText>/proc/paritions, /sys/block, or /dev. It just
allows for more<o:p></o:p></p>
<p class=MsoPlainText>flexibility in specifying SCANORDER and SCANEXCLUDE.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Joel<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>-- <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>"Always give your best, never get discouraged, never
be petty; always<o:p></o:p></p>
<p class=MsoPlainText> remember, others may hate you. Those who hate
you don't win unless<o:p></o:p></p>
<p class=MsoPlainText> you hate them. And then you destroy
yourself."<o:p></o:p></p>
<p class=MsoPlainText> - Richard M. Nixon<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Joel Becker<o:p></o:p></p>
<p class=MsoPlainText>Principal Software Developer<o:p></o:p></p>
<p class=MsoPlainText>Oracle<o:p></o:p></p>
<p class=MsoPlainText>E-mail: joel.becker@oracle.com<o:p></o:p></p>
<p class=MsoPlainText>Phone: (650) 506-8127<o:p></o:p></p>
</div>
</body>
</html>