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 > >