在工作，肯定听到很多关于块设备，字符设备及RAC安装的关联，今天我就对此问题分享一下我的观点，有不对之处敬请大家指出。
字符设备是指在I/O传输过程中以字符为单位进行传输的设备，例如键盘，打印机等。请注意，以字符为单位并不一定意味着是以字节为单位，因为有的编码规则规定，1个字符占16比特，合2个字节。
块设备则好相反，块设备是经过操作系统的，一次可以读出多个字节，将RAC安装中的OCFS就是这种，这种是要在操作系统进行文件格式化的，mkfs.ocfs2 -L "clusterfiles" /dev/sdb1。
这种在编程上就是接口API上调用不一样，设备驱动开发几乎都定义为字符设备的。
说说字符和块设备和RAC安装的前生今世：
在Oracle11g以前（确切地说是在10.2.0.2以前），Oracle只可以使用字符设备作为数据文件，因此需要用raw命令来将块设备绑定为裸设备（字符设备），之后，则可以支持块设备，因此直接用/dev/sda1这样的就O。
小结一下：基本上大家 在搭建RAC的时候都有字符型来做存储，不经过操作系统，特别对于在系统中分析出有IO瓶颈的,用字符设备比对块设备提高40%之上。
下面接下去分析UDEV和多路径了：
DAVE说过Oracle RAC中ASM 的配置可以有2种方式实现：raw和asmlib，而裸设备又有多路径和UDEV.
这里不要小看UDEV，其它搞它就可搞定一切。
一般安装RAC的时候是则专有的存储来划分挂到双机的存储中，存储挂到两边主机显示设备不一样，这时就在用到多路径，有的厂商EMC就有自己的多路径程序，这里是要付费买的，如果没有付费或者其它存储没有多路径，在linux下，本身是自带是多路径的，配置例子如下：
，固定了两边分区之后，这里可以用amslib 和 raw ,配置网上太多，就不详细描述了，这里用什么，各有千秋，
Maclean Liu 总结过的：
Asmlib优缺点：
理论上我们可以从ASMLIB API中得到的以下益处:
总是使用direct,async IO
解决了永久性设备名的问题，即便在重启后设备名已经改变的情况下
解决了文件权限、拥有者的问题
减少了I/O期间从用户模式到内核模式的上下文切换，从而可能降低cpu使用率
减少了文件句柄的使用量
ASMLIB API提供了传递如I/O优先级等元信息到存储设备的可能
ASMLIB可能带来的缺点:
对于多路径设备(multipathing)需要在/etc/sysconfig/oracleasm-_dev_oracleasm配置文件中设置ORACLEASM_SCANORDER及ORACLEASM_SCANEXCLUDE，以便ASMLIB能找到正确的设备文件，具体可以参考Metalink Note<How To Setup ASM & ASMLIB On Native Linux Multipath Mapper disks? [ID 602952.1]>
因为ASM INSTANCE使用ASMLIB提供的asm disk，所以增加了额外的层面
每次Linux Kernel更新，都需要替换新的ASMLIB包
增加了因人为错误造成宕机downtime的可能
使用ASMLIB意味着要花费更多时间去创建和维护
因为ASMLIB的存在，可能引入更多的bug，这是我们最不想看到的
使用ASMLIB创建的disk，其disk header并不会和普通的asm disk header有什么不同，仅仅是在头部多出了ASMLIB的属性空间。真下实际中并无体现。
在实际运用中，怎么顺手用什么，没有谁的优势压倒对方的。
最后附件一下UDEV Multipath 原理图：
udev的主体部分在udevd.c文件中，它主要监控来自4个文件描述符的事件/消息，并做出处理：
1.来自客户端的控制消息。这通常由udevcontrol命令通过地址为/org/kernel/udev/udevd的本地socket，向udevd发送的控制消息。其中消息类型有：
lUDEVD_CTRL_STOP_EXEC_QUEUE停止处理消息队列。
lUDEVD_CTRL_START_EXEC_QUEUE开始处理消息队列。
lUDEVD_CTRL_SET_LOG_LEVEL设置LOG的级别。
lUDEVD_CTRL_SET_MAX_CHILDS设置最大子进程数限制。好像没有用。
lUDEVD_CTRL_SET_MAX_CHILDS_RUNNING设置最大运行子进程数限制(遍历proc目录下所有进程，根据session的值判断)。
lUDEVD_CTRL_RELOAD_RULES重新加载配置文件。
2.来自内核的hotplug事件。如果有事件来源于hotplug，它读取该事件，创建一个udevd_uevent_msg对象，记录当前的消息序列号，设置消息的状态为EVENT_QUEUED,然后并放入running_list和exec_list两个队列中，稍后再进行处理。
3.来自signal handler中的事件。signal handler是异步执行的，即使有signal产生，主进程的select并不会唤醒，为了唤醒主进程的select，它建立了一个管道，在signal handler中，向该管道写入长度为1个子节的数据，这样就可以唤醒主进程的select了。
4.来自配置文件变化的事件。udev通过文件系统inotify功能，监控其配置文件目录/etc/udev/rules.d，一旦该目录中文件有变化，它就重新加载配置文件。
其中最主要的事件，当然是来自内核的hotplug事件，如何处理这些事件是udev的关键。udev本身并不知道如何处理这些事件，也没有必要知道，因为它只实现机制，而不实现策略。事件的处理是由配置文件决定的，这些配置文件即所谓的rule。
Multipath
在光纤组成的SAN环境，由于主机和存储通过了光纤交换机连接，这样的话，
就构成了多对多的关系。也就是说，主机到存储可以有多条路径可以选择。主机到存储之间的IO由多条路径可以选择。好处：多路径”技术使用一个以上的物理路径来访问网络存储设备，并通过容错、I/O流量负载均衡甚至更细粒度的I/O调度策略等方式，为网络存储系统提供更高的可用性和性能优势。
“多路径”软件可以在三个层次上实现：
1.HBA驱动程序：HBA驱动程序将每个磁盘向上层报告为一个块设备，虽然它可能通过多条路径连接到这个磁盘。
2.操作系统内核：对于每个磁盘，HBA报告为不同的块设备，例如/dev/sda和/dev/sdb，操作系统内核将这两个块设备进入“归并”为一个块设备，例如/dev/md0。当前，在Linux中，有两种这样的实现方式：基于Software RAID的多路径技术和基于device mapper的多路径技术。
3.应用程序：例如HDS HDLM、HP SecurePath、EMC PowerPath、Veritas DMP和IBM RDAC。
最后附一个UDEV 配置，
第一种方式：
使用rawdevices服务，进行块设备到字符设备的绑定
# vim /etc/sysconfig/rawdevices
/dev/raw/raw1 /dev/sdb1
/dev/raw/raw2 /dev/sdb2
/dev/raw/raw3 /dev/sdb3
/dev/raw/raw4 /dev/sdb4
# /etc/init.d/rawdevices start
或者 service rawdevices restart
# chkconfig --level 235 rawdevices on
成功开启的标志是：
# /etc/init.d/rawdevices status
/dev/raw/raw1: bound to major 8, minor 17
/dev/raw/raw2: bound to major 8, minor 18
/dev/raw/raw3: bound to major 8, minor 19
/dev/raw/raw4: bound to major 8, minor 20
为裸设备赋予oracle用户的可用权限：
# chown oracle:oinstall /dev/raw/raw1 /dev/raw/raw2 /dev/raw/raw3 /dev/raw/raw4
# ls -l /dev/raw
crw------- 1 oracle oinstall 162, 1 Nov 4 00:34 /dev/raw/raw1
crw------- 1 oracle oinstall 162, 2 Nov 4 00:33 /dev/raw/raw2
crw------- 1 oracle oinstall 162, 3 Nov 4 00:33 /dev/raw/raw3
crw------- 1 oracle oinstall 162, 4 Nov 4 00:34 /dev/raw/raw4
至此，裸设备映射成功，但是，这种方式的配置有一个问题：这些裸设备是在rawdevices服务启动的时候创建的，而rawdevices是以root用户的身份运行的，因此这些裸设备的缺省用户是root:root，所以，每一次服务进行重启的时候，都需要重新修改这些字符设备的权限为oracle:oinsall。
可以在/etc/rc.local中加入对raw设备的权限修改语句，以应对重启系统之后的裸设备文件权限的改变。当重启服务之后，则需要手工执行chown的命令了
第二种方式：
为了解决上面的情况，在此使用mknod提前创建出一个字符方式访问的文件，然后在将文件绑定到块设备上，并把该文件的owner设置为oracle，由于这些映射的字符设备文件是手工创建的，所以这个文件的owner不会因为服务的重启而发生改变：
# mknod /dev/raw/raw1 c 162 1
# mknod /dev/raw/raw2 c 162 2
# mknod /dev/raw/raw3 c 162 3
# mknod /dev/raw/raw4 c 162 4
注意此处的162不能改变，这个是raw设备的主设备编号，后面的数字是raw设备的次设备编号，这个次设备编号可以依次改变
# ll /dev/raw/*
crw-r--r-- 1 root root 162, 1 Nov 4 01:02 raw1
crw-r--r-- 1 root root 162, 2 Nov 4 01:02 raw2
crw-r--r-- 1 root root 162, 3 Nov 4 01:03 raw3
crw-r--r-- 1 root root 162, 4 Nov 4 01:03 raw4
# chown oracle:oinstall /dev/raw/*
# ll /dev/raw/*
crw-r--r-- 1 oracle oinstall 162, 1 Nov 4 01:02 raw1
crw-r--r-- 1 oracle oinstall 162, 2 Nov 4 01:02 raw2
crw-r--r-- 1 oracle oinstall 162, 3 Nov 4 01:03 raw3
crw-r--r-- 1 oracle oinstall 162, 4 Nov 4 01:03 raw4
# vim /etc/sysconfig/rawdevices
/dev/raw/raw1 /dev/sdb1
/dev/raw/raw2 /dev/sdb2
/dev/raw/raw3 /dev/sdb3
/dev/raw/raw4 /dev/sdb4
# service rawdevices restart
# chkconfig --level 235 rawdevices on
第三种方式：
使用udev管理设备的权限
# vi /etc/udev/rules.d/60-raw.rules
ACTION=="add",KERNEL=="sdb1",RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="17",RUN+="/bin/raw /dev/raw/raw1 %m"
ACTION=="add",KERNEL=="sdb2",RUN+="/bin/raw /dev/raw/raw2 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="18",RUN+="/bin/raw /dev/raw/raw2 %m"
ACTION=="add",KERNEL=="sdb3",RUN+="/bin/raw /dev/raw/raw3 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="19",RUN+="/bin/raw /dev/raw/raw3 %m"
ACTION=="add",KERNEL=="sdb4",RUN+="/bin/raw /dev/raw/raw4 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="20",RUN+="/bin/raw /dev/raw/raw4 %m"
ACTION=="add",KERNEL=="raw[1-4]",OWNER=="oracle",GROUP="oinstall",MODE="640"
其中major是设备的主设备编号，minor是次设备编号，最后一行是设置已设置裸设备的文件权限
如此，就可以不用担心rawdevices重启之后的设备文件权限的变化了。
# /bin/cat /etc/udev/rules.d/99-raw.rules
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="3600805f30016c0e0ad41ffa8e6d90001", NAME="raw1", ACTION=="add|change", OWNER="root", GROUP="oinstall", MODE="0640"
第三种配置在新版本了，第一种在以前老版本，具体是以Redhat 5为分界线。
字符设备 块设备 rac 安装 千屡万丝,布布扣,bubuko.com
原文：http://startliu.blog.51cto.com/1758520/1377253