Re: ASM bug?

From: Maureen English <maureen.english_at_alaska.edu>
Date: Thu, 02 Oct 2014 08:55:13 -0800
Message-ID: <542D8371.8010307_at_alaska.edu>


  
    
  
  
    Stefan, Andew;

Yes, we are using ASMLIB.

- Maureen

On 10/2/2014 7:56 AM, Andrew Kerber wrote:
I am pretty sure the labels she mentions and the disk scanning are the ASMLIB methods

Sent from my iPhone

On Oct 2, 2014, at 10:26 AM, Stefan Koehler <contact_at_soocs.de> wrote:

Hi Andrew,
for sure - is she using ASMLIB? 
 
I may have missed some posting about that, otherwise Maureen may provide this information in addition later on. However the persistent device naming (multipath binding) is also needed / recommended with ASMLIB (scan order). I personally would go for udev anyway :-))
 
Best Regards
Stefan Koehler
 
Andrew Kerber <andrew.kerber_at_gmail.com> hat am 2. Oktober 2014 um 17:06 geschrieben:

Sounds like a bug.  If she is using ASMLIB, she does not use Udev.  The two are mutually exclusive.

Sent from my iPhone

On Oct 2, 2014, at 2:53 AM, Stefan Koehler < contact_at_soocs.de> wrote:

Hi Maureen,
that's no bug. You have to use persistent device naming (multipath binding) by multipathd and udev rules to set the correct device permission / owner.
 
However be aware of the suggested multipath settings by every storage vendor (e.g. fail_if_no_path with NetApp) and ASM. In some cases you are not able to flush the device map due to such suggestions after a path failure, even if the disk is not used by ASM anymore.
 
Best Regards
Stefan Koehler
 
Oracle  p erformance consultant and researcher
 
Maureen English < maureen.english_at_alaska.edu> hat am 2. Oktober 2014 um 02:34 geschrieben:

device-mapper-multipath


On 10/1/2014 4:27 PM, Dimensional DBA wrote:
What Multipathing SW are you using?

Matthew Parker
Chief Technologist
425-891-7934 (cell)
Dimensional.dba_at_comcast.net
View Matthew Parker's profile on LinkedIn


-----Original Message-----
From: Dimensional DBA [mailto:dimensional.dba_at_comcast.net] 
Sent: Wednesday, October 01, 2014 5:23 PM
To: 'maureen.english_at_alaska.edu'; 'oracle-l_at_freelists.org'
Subject: RE: ASM bug?

Did you put the disk id's in the multipath.conf file which hard sets the
mapping?


Matthew Parker
Chief Technologist
425-891-7934 (cell)
Dimensional.dba_at_comcast.net
View Matthew Parker's profile on LinkedIn


-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Maureen English
Sent: Wednesday, October 01, 2014 4:44 PM
To: oracle-l_at_freelists.org
Subject: ASM bug?

We're building a new system and the sysadmin and dba working on it
discovered a problem.
This is RHEL5 and Oracle 11.2.0.4 RAC.

At boot, or when instructed to do so, Oracle ASM scans disks and 
creates an index of which ASM labels are on which disks, however it 
does not do anything to tell the kernel that it intends to use the disks
it has identified.  It is not until ASM mounts the disks in a diskgroup that
it marks them as "in use".
Until a disk is actually in use (opened), the kernel will happily 
unmap or re-map dm devices that Oracle ASM has already scanned. Oracle 
ASM will try to modify the wrong disk if the kernel remaps an unused dm
device to a different disk before ASM mounts it.
When multipath is run with the -F option, it will flush all multipath 
devices that are not in use.  When multipath re-maps the devices, it 
may assign different device numbers to the disks it flushed.  There is 
no way to tell Oracle ASM to forget about a label it has scanned 
without deleting the ASM labels off the disk or rebooting the system.  It
is very important not to flush a disk that ASM has already identified.  Do
not use multipath -F if there are any unmounted ASM disks presented to the
system.

Is this a known bug, or are there some rules regarding ASM and multipath
that we missed?

I'm not actually working on this system, but thought it sounds like
something others would have encountered.  I'm still searching through
Metalink docs....

- Maureen

--
http://www.freelists.org/webpage/oracle-l



-- 
Maureen English
Lead Database Administrator
University of Alaska
Fairbanks, AK
(907) 450-8329

 
-- http://www.freelists.org/webpage/oracle-l
-- http://www.freelists.org/webpage/oracle-l

 

-- 
Maureen English
Lead Database Administrator
University of Alaska
Fairbanks, AK
(907) 450-8329
-- http://www.freelists.org/webpage/oracle-l Received on Thu Oct 02 2014 - 18:55:13 CEST

Original text of this message