Re: ASM bug?

  • From: Andrew Kerber <andrew.kerber@xxxxxxxxx>
  • To: Stefan Koehler <contact@xxxxxxxx>
  • Date: Thu, 2 Oct 2014 10:56:20 -0500

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@xxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxx> 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
>>> http://www.soocs.de
>>>  
>>>> Maureen English < maureen.english@xxxxxxxxxx> 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@xxxxxxxxxxx
>>>>> View Matthew Parker's profile on LinkedIn
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Dimensional DBA [mailto:dimensional.dba@xxxxxxxxxxx] 
>>>>> Sent: Wednesday, October 01, 2014 5:23 PM
>>>>> To: 'maureen.english@xxxxxxxxxx'; 'oracle-l@xxxxxxxxxxxxx'
>>>>> 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@xxxxxxxxxxx
>>>>> View Matthew Parker's profile on LinkedIn
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
>>>>> On Behalf Of Maureen English
>>>>> Sent: Wednesday, October 01, 2014 4:44 PM
>>>>> To: oracle-l@xxxxxxxxxxxxx
>>>>> 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
>>>>> 
>>>>> --
>>>>> //www.freelists.org/webpage/oracle-l
>>>>> 
>>>>> 
>>>> 
>>>> -- 
>>>> Maureen English
>>>> Lead Database Administrator
>>>> University of Alaska
>>>> Fairbanks, AK
>>>> (907) 450-8329
>>> 
>>>  
>>>> -- //www.freelists.org/webpage/oracle-l
>>> -- //www.freelists.org/webpage/oracle-l
> 
>  

Other related posts: