当使用ASMLIB 来管理ASM 磁盘时，设备的路径信息是不会在gv$asm_disk视图path列中显示的，如果你使用的是ASMLIB Support Tools 2.1 或者更高（oracleasm-support-2.1*的rpm包）版本,可以通过root用户运行'oracleasm querydisk -p'来获得设备路径信息:
# ls -l /dev/oracleasm/disks
total 0
brw-rw---- 1 grid asmadmin 8, 5 May 2 12:00 DISK1
brw-rw---- 1 grid asmadmin 8, 6 May 2 12:00 DISK2
brw-rw---- 1 grid asmadmin 8, 7 May 2 12:00 DISK3
...
# oracleasm querydisk -p DISK1
Disk "DISK1" is a valid ASM disk
/dev/sda5: LABEL="DISK1" TYPE="oracleasm"
译者注：译者并不推荐使用asmlib来管理ASM的磁盘，asmlib的出现本质上是为了解决设备权限、设备拥有者信息的问题，还可以提供一个“永不变化”的设备名，但是linux原生的udev同样可以做到这一点，而且做的更好，ASM INSTANCE使用ASMLIB提供的asm disk，增加了额外的层面，每次Linux Kernel更新，都需要替换新的ASMLIB包，ASMLIB的存在，还可能引入更多的bug。特别是，如果是在RHEL/OEL 5或以上版本，udev已非常成熟，你已经有充分的理由利用udev而放弃ASMLIB。
另外，通过下面的shell脚本也可以查看
#!/bin/bash
for asmlibdisk in `ls /dev/oracleasm/disks/*`
do
echo "ASMLIB disk name: $asmlibdisk"
asmdisk=`kfed read $asmlibdisk | grep dskname | tr -s ' '| cut -f2 -d' '`
echo "ASM disk name: $asmdisk"
majorminor=`ls -l $asmlibdisk | tr -s ' ' | cut -f5,6 -d' '`
device=`ls -l /dev | tr -s ' ' | grep "$majorminor" | cut -f10 -d' '`
echo "Device path: /dev/$device"
done
上面脚本是要通过操作系统中ASM或GI的owner用户执行，当然kfed二进制文件必须是已经可以使用并在相关的PATH环境变量中。运行以上命令不必使用root特权用户。
如果一个ASMLIB 磁盘已经被删除掉，那/dev/oracleasm/disks下就看不到相关的磁盘，可以通过下面的脚本来检查设备是否和ASM有关系（曾经有关系）。
#!/bin/bash
for device in `ls /dev/sd*`
do
asmdisk=`kfed read $device|grep ORCL|tr -s ' '|cut -f2 -d' '|cut -c1-4`
if [ "$asmdisk" = "ORCL" ]
then
echo "Disk device $device may be an ASM disk"
fi
done
译者注：其实使用asmlib方式管理磁盘，跟使用udev管理磁盘并没有什么不同，asmlib方式管理的磁盘，也只是在磁盘头的kfdhdb.driver.provstr位置记录了它是asmlib管理的磁盘而已,格式为：ORCLDISK+[ASM disk name]，如果不是asmlib管理的磁盘，kfdhdb.driver.provstr记录的信息为ORCLDISK。
上面的脚本将扫描/dev下sd关键字打头的设备，除了kfed要在PATH 路径中之外，脚本还需要使用用超级用户运行。当然，你也可以去扫描/dev/dm*, /dev/mapper下面的设备甚至/dev/下面所有的设备，但这可能并不高效。
最近有一个问题是关于怎么样不使用kfed来达到上面操作能实现的功能，下面给出的就是一种解决办法：
#!/bin/bash
for device in `ls /dev/sd*`
do
asmdisk=`od -c $device | head | grep 0000040 | tr -d ' ' | cut -c8-11`
if [ "$asmdisk" = "ORCL" ]
then
echo "Disk device $device may be an ASM disk"
fi
done
本文来自云栖社区合作伙伴“DBGEEK”