start_udev 是不是会写磁盘头
遇到一个案例，在这里记录一下
一套Oracle 11.2.0.4 RAC环境，操作系统是RHEL 6.5，共享磁盘是通过UDEV实现RAW绑定设备名，如下
[root@rac1 opt]# ll /dev/sd*
brw-rw----. 1 root disk 8, 0 Dec 2 20:26 /dev/sda
brw-rw----. 1 root disk 8, 1 Dec 2 20:26 /dev/sda1
brw-rw----. 1 root disk 8, 2 Dec 2 20:26 /dev/sda2
brw-rw----. 1 root disk 8, 16 Dec 2 20:26 /dev/sdb
brw-rw----. 1 root disk 8, 17 Dec 2 20:26 /dev/sdb1
brw-rw----. 1 root disk 8, 32 Dec 2 20:26 /dev/sdc
brw-rw----. 1 root disk 8, 33 Dec 2 20:26 /dev/sdc1
brw-rw----. 1 root disk 8, 48 Dec 2 20:26 /dev/sdd
brw-rw----. 1 root disk 8, 49 Dec 2 20:26 /dev/sdd1
brw-rw----. 1 root disk 8, 64 Dec 2 20:26 /dev/sde
brw-rw----. 1 root disk 8, 65 Dec 2 20:26 /dev/sde1
[root@rac1 opt]# cat /etc/udev/rules.d/60-raw.rules
# Enter raw device bindings here.
#
# An example would be:
# ACTION=="add", KERNEL=="sda", RUN+="/bin/raw /dev/raw/raw1 %N"
# to bind /dev/raw/raw1 to /dev/sda, or
# ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="1", RUN+="/bin/raw /dev/raw/raw2 %M %m"
# to bind /dev/raw/raw2 to the device with major 8, minor 1. ACTION=="add",KERNEL=="/dev/sdb1",RUN+='/bin/raw /dev/raw/raw1 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="17",RUN+="/bin/raw /dev/raw/raw1 %M %m"
ACTION=="add",KERNEL=="/dev/sdc1",RUN+='/bin/raw /dev/raw/raw2 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="33",RUN+="/bin/raw /dev/raw/raw2 %M %m"
ACTION=="add",KERNEL=="/dev/sdd1",RUN+='/bin/raw /dev/raw/raw3 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="49",RUN+="/bin/raw /dev/raw/raw3 %M %m"
ACTION=="add",KERNEL=="/dev/sde1",RUN+='/bin/raw /dev/raw/raw4 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="65",RUN+="/bin/raw /dev/raw/raw4 %M %m"
KERNEL=="raw[1-4]",OWNER="grid",GROUP="asmadmin",MODE="660"
[root@rac1 opt]# ll /dev/raw
total 0
crw-rw----. 1 grid asmadmin 162, 1 Dec 2 21:09 raw1
crw-rw----. 1 grid asmadmin 162, 2 Dec 2 21:09 raw2
crw-rw----. 1 grid asmadmin 162, 3 Dec 2 21:09 raw3
crw-rw----. 1 grid asmadmin 162, 4 Dec 2 20:26 raw4
crw-rw----. 1 root disk 162, 0 Dec 2 20:26 rawctl
一天，由于磁盘出现IO问题，导致RAC经常重启，存储修复磁盘切换了存储链路，导致映射到OS上的存储设备名发生了改变，导致UDEV绑定失败
下面修改UDEV的绑定方式，通过UUID绑定磁盘，如下
[root@rac1 ~]# for i in `cat /proc/partitions | awk '{print $4}' |grep sd | grep [a-z]$`; do echo "### $i: `scsi_id -g -u -d /dev/$i`"; done
### sda: 1ATA_VBOX_HARDDISK_VB85d0d4ba-e17b3dda
### sdb: 1ATA_VBOX_HARDDISK_VBc325912a-0addf096
### sdc: 1ATA_VBOX_HARDDISK_VB03a27735-42af5dea
### sdd: 1ATA_VBOX_HARDDISK_VB207dd3a2-a2f610c4
### sde: 1ATA_VBOX_HARDDISK_VBbc4b578d-a8e62d78
vi /etc/udev/rules.d/99-asm-oracle.rules
ACTION=="add",BUS=="scsi", KERNEL=="sd*", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="1ATA_VBOX_HARDDISK_VBc325912a-0addf096", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add",BUS=="scsi", KERNEL=="sd*", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="1ATA_VBOX_HARDDISK_VB03a27735-42af5dea", RUN+="/bin/raw /dev/raw/raw2 %N"
ACTION=="add",BUS=="scsi", KERNEL=="sd*", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="1ATA_VBOX_HARDDISK_VB207dd3a2-a2f610c4", RUN+="/bin/raw /dev/raw/raw3 %N"
ACTION=="add",BUS=="scsi", KERNEL=="sd*", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="1ATA_VBOX_HARDDISK_VBbc4b578d-a8e62d78", RUN+="/bin/raw /dev/raw/raw4 %N"
KERNEL=="raw[1-4]",OWNER="grid",GROUP="asmadmin",MODE="0660"
删除 /etc/udev/rules.d/60-raw.rules 文件的绑定方式，关闭了所有节点的CRS，重新启动UDEV
[root@rac1 ~]# /u01/app/11.2.0/grid/bin/crsctl stop crs
[root@rac2 ~]# /u01/app/11.2.0/grid/bin/crsctl stop crs
[root@rac1 ~]# start_udev
启动CRS，发现CRS识别不到表决磁盘，crs alter报错信息如下
[root@rac1 rac1]# tail -f alertrac1.log [ohasd(5337)]CRS-2767:Resource state recovery not attempted for 'ora.diskmon' as its target state is OFFLINE
2019-12-02 21:20:40.230:
[ohasd(5337)]CRS-2769:Unable to failover resource 'ora.diskmon'.
2019-12-02 21:20:42.580:
[cssd(6272)]CRS-1714:Unable to discover any voting files, retrying discovery in 15 seconds; Details at (:CSSNM00070:) in /u01/app/11.2.0/grid/log/rac1/cssd/ocssd.log
2019-12-02 21:20:57.605:
[cssd(6272)]CRS-1714:Unable to discover any voting files, retrying discovery in 15 seconds; Details at (:CSSNM00070:) in /u01/app/11.2.0/grid/log/rac1/cssd/ocssd.log
ocssd.log的报错信息如下：
[root@rac1 ~]# tail -f /u01/app/11.2.0/grid/log/rac1/cssd/ocssd.log 2019-12-02 21:21:27.636: [ SKGFD][411584256]Execute glob on the string /dev/raw/*
2019-12-02 21:21:27.636: [ SKGFD][411584256]running stat on disk:/dev/raw/raw1
2019-12-02 21:21:27.636: [ SKGFD][411584256]running stat on disk:/dev/raw/raw3
2019-12-02 21:21:27.636: [ SKGFD][411584256]running stat on disk:/dev/raw/raw2
2019-12-02 21:21:27.636: [ SKGFD][411584256]running stat on disk:/dev/raw/raw4
2019-12-02 21:21:27.636: [ SKGFD][411584256]running stat on disk:/dev/raw/rawctl
2019-12-02 21:21:27.636: [ SKGFD][411584256]Fetching UFS disk :/dev/raw/rawctl: 2019-12-02 21:21:27.637: [ SKGFD][411584256]Fetching UFS disk :/dev/raw/raw4: 2019-12-02 21:21:27.637: [ SKGFD][411584256]Fetching UFS disk :/dev/raw/raw2: 2019-12-02 21:21:27.637: [ SKGFD][411584256]Fetching UFS disk :/dev/raw/raw3: 2019-12-02 21:21:27.637: [ SKGFD][411584256]Fetching UFS disk :/dev/raw/raw1: 2019-12-02 21:21:27.637: [ SKGFD][411584256]OSS discovery with :: 2019-12-02 21:21:27.638: [ SKGFD][411584256]Handle 0x7f8704140a50 from lib :UFS:: for disk :/dev/raw/raw4: 2019-12-02 21:21:27.638: [ SKGFD][411584256]Handle 0x7f8704138d60 from lib :UFS:: for disk :/dev/raw/raw2: 2019-12-02 21:21:27.638: [ SKGFD][411584256]Handle 0x7f8704139590 from lib :UFS:: for disk :/dev/raw/raw3: 2019-12-02 21:21:27.638: [ SKGFD][411584256]Handle 0x7f8704141e40 from lib :UFS:: for disk :/dev/raw/raw1: 2019-12-02 21:21:27.639: [ SKGFD][411584256]Lib :UFS:: closing handle 0x7f8704140a50 for disk :/dev/raw/raw4: 2019-12-02 21:21:27.639: [ SKGFD][411584256]Lib :UFS:: closing handle 0x7f8704138d60 for disk :/dev/raw/raw2: 2019-12-02 21:21:27.639: [ SKGFD][411584256]Lib :UFS:: closing handle 0x7f8704139590 for disk :/dev/raw/raw3: 2019-12-02 21:21:27.639: [ SKGFD][411584256]Lib :UFS:: closing handle 0x7f8704141e40 for disk :/dev/raw/raw1: 2019-12-02 21:21:27.639: [ CSSD][411584256]clssnmvDiskVerify: Successful discovery of 0 disks
2019-12-02 21:21:27.639: [ CSSD][411584256]clssnmCompleteInitVFDiscovery: Completing initial voting file discovery
2019-12-02 21:21:27.639: [ CSSD][411584256]clssnmvFindInitialConfigs: No voting files found
2019-12-02 21:21:27.639: [ CSSD][411584256](:CSSNM00070:)clssnmCompleteInitVFDiscovery: Voting file not found. Retrying discovery in 15 seconds
2019-12-02 21:21:27.766: [ CSSD][414275328]clssscSelect: cookie accept request 0x7f8710083a90
2019-12-02 21:21:27.766: [ CSSD][414275328]clssscevtypSHRCON: getting client with cmproc 0x7f8710083a90
2019-12-02 21:21:27.766: [ CSSD][414275328]clssgmRegisterClient: proc(5/0x7f8710083a90), client(40/0x7f8710063d30)
2019-12-02 21:21:27.766: [ CSSD][414275328]clssgmExecuteClientRequest(): type(6) size(684) only connect and exit messages are allowed before lease acquisition proc(0x7f8710083a90) client(0x7f8710063d30)
2019-12-02 21:21:27.766: [ CSSD][414275328]clssgmDiscEndpcl: gipcDestroy 0xdcc
2019-12-02 21:21:28.521: [ CSSD][414275328]clssscSelect: cookie accept request 0x7f871006f0b0
2019-12-02 21:21:28.521: [ CSSD][414275328]clssscevtypSHRCON: getting client with cmproc 0x7f871006f0b0
2019-12-02 21:21:28.521: [ CSSD][414275328]clssgmRegisterClient: proc(3/0x7f871006f0b0), client(42/0x7f8710063d30)
2019-12-02 21:21:28.521: [ CSSD][414275328]clssgmExecuteClientRequest(): type(6) size(684) only connect and exit messages are allowed before lease acquisition proc(0x7f871006f0b0) client(0x7f8710063d30)
2019-12-02 21:21:28.521: [ CSSD][414275328]clssgmDiscEndpcl: gipcDestroy 0xde2
2019-12-02 21:21:28.767: [ CSSD][414275328]clssscSelect: cookie accept request 0x7f8710083a90
2019-12-02 21:21:28.767: [ CSSD][414275328]clssscevtypSHRCON: getting client with cmproc 0x7f8710083a90
2019-12-02 21:21:28.767: [ CSSD][414275328]clssgmRegisterClient: proc(5/0x7f8710083a90), client(41/0x7f8710096260)
2019-12-02 21:21:28.767: [ CSSD][414275328]clssgmExecuteClientRequest(): type(6) size(684) only connect and exit messages are allowed before lease acquisition proc(0x7f8710083a90) client(0x7f8710096260)
2019-12-02 21:21:28.767: [ CSSD][414275328]clssgmDiscEndpcl: gipcDestroy 0xdf8
rac1:/home/grid$ kfod asm_diskstring='/dev/raw/*' disks=all
--------------------------------------------------------------------------------
Disk Size Path User Group
================================================================================
1: 1019 Mb /dev/raw/raw1 grid asmadmin
2: 1019 Mb /dev/raw/raw2 grid asmadmin
3: 1019 Mb /dev/raw/raw3 grid asmadmin
4: 8189 Mb /dev/raw/raw4 grid asmadmin
KFOD-00301: Unable to contact Cluster Synchronization Services (CSS). Return code 2 from kgxgncin.
KFOD-00311: Error scanning device /dev/raw/rawctl
ORA-15025: could not open disk "/dev/raw/rawctl"
Linux-x86_64 Error: 13: Permission denied
Additional information: 42
rac1:/home/grid$ kfed read /dev/raw/raw1
kfbh.endian: 0 ; 0x000: 0x00
kfbh.hard: 0 ; 0x001: 0x00
kfbh.type: 0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt: 0 ; 0x003: 0x00
kfbh.block.blk: 0 ; 0x004: blk=0
kfbh.block.obj: 0 ; 0x008: file=0
kfbh.check: 0 ; 0x00c: 0x00000000
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
7FCB36A16400 00000000 00000000 00000000 00000000 [................]
Repeat 26 times
7FCB36A165B0 00000000 00000000 BB43868B 01000000 [..........C.....]
7FCB36A165C0 FE830001 003F813F DDC30000 0000001F [....?.?.........]
7FCB36A165D0 00000000 00000000 00000000 00000000 [................]
Repeat 1 times
7FCB36A165F0 00000000 00000000 00000000 AA550000 [..............U.]
7FCB36A16600 00000000 00000000 00000000 00000000 [................]
Repeat 223 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
将UDEV的绑定方式从绑定设备的UUID改回原来的绑定设备名，start_udev，磁盘恢复正常，集群启动成功。
[root@rac1 opt]# cat /etc/udev/rules.d/60-raw.rules
# Enter raw device bindings here.
#
# An example would be:
# ACTION=="add", KERNEL=="sda", RUN+="/bin/raw /dev/raw/raw1 %N"
# to bind /dev/raw/raw1 to /dev/sda, or
# ACTION=="add", ENV{MAJOR}=="8", ENV{MINOR}=="1", RUN+="/bin/raw /dev/raw/raw2 %M %m"
# to bind /dev/raw/raw2 to the device with major 8, minor 1. ACTION=="add",KERNEL=="/dev/sdb1",RUN+='/bin/raw /dev/raw/raw1 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="17",RUN+="/bin/raw /dev/raw/raw1 %M %m"
ACTION=="add",KERNEL=="/dev/sdc1",RUN+='/bin/raw /dev/raw/raw2 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="33",RUN+="/bin/raw /dev/raw/raw2 %M %m"
ACTION=="add",KERNEL=="/dev/sdd1",RUN+='/bin/raw /dev/raw/raw3 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="49",RUN+="/bin/raw /dev/raw/raw3 %M %m"
ACTION=="add",KERNEL=="/dev/sde1",RUN+='/bin/raw /dev/raw/raw4 %N"
ACTION=="add",ENV{MAJOR}=="8",ENV{MINOR}=="65",RUN+="/bin/raw /dev/raw/raw4 %M %m"
KERNEL=="raw[1-4]",OWNER="grid",GROUP="asmadmin",MODE="660"
rac1:/home/grid$ kfed read /dev/raw/raw1
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: blk=0
kfbh.block.obj: 2147483648 ; 0x008: disk=0
kfbh.check: 1914149503 ; 0x00c: 0x72179a7f
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000
kfdhdb.compat: 186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum: 0 ; 0x024: 0x0000
kfdhdb.grptyp: 2 ; 0x026: KFDGTP_NORMAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: CRS_0000 ; 0x028: length=8
kfdhdb.grpname: CRS ; 0x048: length=3
kfdhdb.fgname: CRS_0000 ; 0x068: length=8
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 33091668 ; 0x0a8: HOUR=0x14 DAYS=0x2 MNTH=0xc YEAR=0x7e3
kfdhdb.crestmp.lo: 3665632256 ; 0x0ac: USEC=0x0 MSEC=0x347 SECS=0x27 MINS=0x36
kfdhdb.mntstmp.hi: 33091668 ; 0x0b0: HOUR=0x14 DAYS=0x2 MNTH=0xc YEAR=0x7e3
kfdhdb.mntstmp.lo: 3884250112 ; 0x0b4: USEC=0x0 MSEC=0x13d SECS=0x38 MINS=0x39
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 1019 ; 0x0c4: 0x000003fb
kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]: 0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]: 0 ; 0x0dc: 0x0000
kfdhdb.redomirrors[3]: 0 ; 0x0de: 0x0000
kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi: 33091668 ; 0x0e4: HOUR=0x14 DAYS=0x2 MNTH=0xc YEAR=0x7e3
kfdhdb.grpstmp.lo: 3665294336 ; 0x0e8: USEC=0x0 MSEC=0x1fd SECS=0x27 MINS=0x36
kfdhdb.vfstart: 256 ; 0x0ec: 0x00000100
kfdhdb.vfend: 288 ; 0x0f0: 0x00000120
kfdhdb.spfile: 59 ; 0x0f4: 0x0000003b
kfdhdb.spfflg: 1 ; 0x0f8: 0x00000001
kfdhdb.ub4spare[0]: 0 ; 0x0fc: 0x00000000
kfdhdb.ub4spare[1]: 0 ; 0x100: 0x00000000
kfdhdb.ub4spare[2]: 0 ; 0x104: 0x00000000
kfdhdb.ub4spare[3]: 0 ; 0x108: 0x00000000
kfdhdb.ub4spare[4]: 0 ; 0x10c: 0x00000000
kfdhdb.ub4spare[5]: 0 ; 0x110: 0x00000000
kfdhdb.ub4spare[6]: 0 ; 0x114: 0x00000000
kfdhdb.ub4spare[7]: 0 ; 0x118: 0x00000000
kfdhdb.ub4spare[8]: 0 ; 0x11c: 0x00000000
kfdhdb.ub4spare[9]: 0 ; 0x120: 0x00000000
kfdhdb.ub4spare[10]: 0 ; 0x124: 0x00000000
kfdhdb.ub4spare[11]: 0 ; 0x128: 0x00000000
kfdhdb.ub4spare[12]: 0 ; 0x12c: 0x00000000
kfdhdb.ub4spare[13]: 0 ; 0x130: 0x00000000
kfdhdb.ub4spare[14]: 0 ; 0x134: 0x00000000
kfdhdb.ub4spare[15]: 0 ; 0x138: 0x00000000
kfdhdb.ub4spare[16]: 0 ; 0x13c: 0x00000000
kfdhdb.ub4spare[17]: 0 ; 0x140: 0x00000000
kfdhdb.ub4spare[18]: 0 ; 0x144: 0x00000000
kfdhdb.ub4spare[19]: 0 ; 0x148: 0x00000000
kfdhdb.ub4spare[20]: 0 ; 0x14c: 0x00000000
kfdhdb.ub4spare[21]: 0 ; 0x150: 0x00000000
kfdhdb.ub4spare[22]: 0 ; 0x154: 0x00000000
kfdhdb.ub4spare[23]: 0 ; 0x158: 0x00000000
kfdhdb.ub4spare[24]: 0 ; 0x15c: 0x00000000
kfdhdb.ub4spare[25]: 0 ; 0x160: 0x00000000
kfdhdb.ub4spare[26]: 0 ; 0x164: 0x00000000
kfdhdb.ub4spare[27]: 0 ; 0x168: 0x00000000
kfdhdb.ub4spare[28]: 0 ; 0x16c: 0x00000000
kfdhdb.ub4spare[29]: 0 ; 0x170: 0x00000000
kfdhdb.ub4spare[30]: 0 ; 0x174: 0x00000000
kfdhdb.ub4spare[31]: 0 ; 0x178: 0x00000000
kfdhdb.ub4spare[32]: 0 ; 0x17c: 0x00000000
kfdhdb.ub4spare[33]: 0 ; 0x180: 0x00000000
kfdhdb.ub4spare[34]: 0 ; 0x184: 0x00000000
kfdhdb.ub4spare[35]: 0 ; 0x188: 0x00000000
kfdhdb.ub4spare[36]: 0 ; 0x18c: 0x00000000
kfdhdb.ub4spare[37]: 0 ; 0x190: 0x00000000
kfdhdb.ub4spare[38]: 0 ; 0x194: 0x00000000
kfdhdb.ub4spare[39]: 0 ; 0x198: 0x00000000
kfdhdb.ub4spare[40]: 0 ; 0x19c: 0x00000000
kfdhdb.ub4spare[41]: 0 ; 0x1a0: 0x00000000
kfdhdb.ub4spare[42]: 0 ; 0x1a4: 0x00000000
kfdhdb.ub4spare[43]: 0 ; 0x1a8: 0x00000000
kfdhdb.ub4spare[44]: 0 ; 0x1ac: 0x00000000
kfdhdb.ub4spare[45]: 0 ; 0x1b0: 0x00000000
kfdhdb.ub4spare[46]: 0 ; 0x1b4: 0x00000000
kfdhdb.ub4spare[47]: 0 ; 0x1b8: 0x00000000
kfdhdb.ub4spare[48]: 0 ; 0x1bc: 0x00000000
kfdhdb.ub4spare[49]: 0 ; 0x1c0: 0x00000000
kfdhdb.ub4spare[50]: 0 ; 0x1c4: 0x00000000
kfdhdb.ub4spare[51]: 0 ; 0x1c8: 0x00000000
kfdhdb.ub4spare[52]: 0 ; 0x1cc: 0x00000000
kfdhdb.ub4spare[53]: 0 ; 0x1d0: 0x00000000
kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000
kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000
kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000
kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000
这里有个疑问，udev 更改磁盘绑定策略 （ 由之前绑定盘名 改为 绑定 uuid ）, start_udev 会写磁盘头？？
这个环境中有4块共享磁盘，raw1-3是集群的CRS磁盘，raw4还没有给集群使用
1. 下面使用dd命令，分别对udev绑定设备名和绑定UUID后的raw1进行dd磁盘前4K
rac1:/home/grid$ dd if=/dev/raw/raw1 of=/tmp/raw1.txt bs=1k count=4
udev绑定设备名的raw1前4K，能看出来有CRS磁盘组信息
udev绑定UUID的raw1前4K，能看出来磁盘头有改名，磁盘组信息消失
2. 因为 raw4 没有被RAC使用，先使用dd命令清空磁盘头，dd磁盘前4K，再执行 start_udev ，再dd磁盘前4K，进行对比
# dd if=/dev/zero of=/dev/raw/raw4 bs=1M count=30
$ dd if=/dev/raw/raw4 of=/tmp/raw4.txt bs=1k count=4
执行 start_udev 前的 raw4 的前4K，能看出来是空的
执行 start_udev 后的 raw4 的前4K
start_udev 是不是会写磁盘头的更多相关文章
- ASM 磁盘头信息备份
ASM磁盘头信息保存在每个磁盘的前4K里面,这个信息的备份对于ASM的恢复非常重要,有下面的几种方 1.直接做dd来备份磁盘的前4K,磁盘头信息丢失时,dd回来 备份:dd if=/dev/raw/r ...
- 关闭Centos写磁盘功能
一个Linux文件默认有3个时间.atime:对此文件的访问时间. ctime:此文件inode发生变化的时间. mtime:此文件的修改时间. 如果有多个小文件(比如Web服务器的页面上有多个小图片 ...
- redis 验证消息队列也是写磁盘的
# 下面的例子将会进行把数据写入磁盘的操作: # 900秒(15分钟)之后,且至少1次变更 # 300秒(5分钟)之后,且至少10次变更 # 60秒之后,且至少10000次变更 # # 注意:你要想不 ...
- 关闭Centos5.5的写磁盘I/O功能
一个Linux文件默认有3个时间. atime:对此文件的访问时间. ctime:此文件inode发生变化的时间. mtime:此文件的修改时间. 如果有多个小文件(比如Web服务器的页面上有多个小图 ...
- C++模板类代码只能写在头文件？
这个问题,实际上我几年前就遇到了.最近写个模板类玩的时候,再次遇到. 当我非常仔细的将定义和实现分开,在头文件中保留了最少的依赖后,一切就绪.cpp单独编过.但是当使用的时候,就会报告所有的函 ...
- logback日志大量写磁盘导致微服务不能正常响应的解决方案
最近几天,遇到一个莫名其妙的问题,每天几乎同一时段微服务自己跑着跑着就假死了,过几个小时就又自动恢复了. 通过对定时任务.网卡.内存.磁盘.业务日志的排查分析,只有磁盘的IO在假死前一段时间偏高,经查 ...
- redis 写磁盘出错 Can’t save in background: fork: Cannot allocate memory (转)
查看 Redis 日志 发现系统在频繁报错: [26641] 18 Dec 04:02:14 * 1 changes in 900 seconds. Saving… [26641] 18 Dec 04 ...
- redis写磁盘报错Cannot allocate memory
查看 Redis 日志发现系统在频繁报错: [1821] 10 Nov 09:59:04.086 # Can't save in background: fork: Cannot allocate m ...
- C++中头文件（.h）和源文件（.cpp）都应该写些什么
头文件(.h): 写类的声明(包括类里面的成员和方法的声明).函数原型.#define常数等,但一般来说不写出具体的实现. 在写头文件时需要注意,在开头和结尾处必须按照如下样式加上预编译语句(如下): ...
随机推荐
- 微信 电脑版 HOOK（WeChat PC Hook）- 框架
软件构成:一个主进程exe和一个注入的dll主进程exe:把dll注入到微信,发送指令给dll,接受dll的信息注入的dll:被注入到微信内部,拦截微信的数据,调用微信的功能 接收主进程的指令,执行指 ...
- CSDN屏蔽广告
CSDN俨然是一家广告网站了,各种广告层出不穷,且毫无底线.经常性的展示一些植发.防脱的广告,实在影响心情.另外,在复制内容的时候,会通过js给你带上一段来源,对于版权保护这是好事儿,但是对于直接复制 ...
- java之java.io.File的相关方法
java.io.File的使用. IO原理及流的分类. 文件流:FileInputStream.FileOutputStream.FileReader.FileWriter 缓存流:BufferedI ...
- ps -ef |grep -v 在shell sh 脚本中貌似无效？
想通过ps -ef |grep erdp_ |awk '{print $2}' 获取 erdp_ 开头的进程id, 执行在终端环境下执行是ok的,但是在 sh 脚本里面竟然多出了 两个 root 11 ...
- centos7 laravel 项目 npm install报错
npm install 初始化项目依赖的前端资源 报错 ERR xxx .. socket,symbol link is not supported ... 如果报错了 重新npm install ...
- mysql5.5下载安装教程
下载地址:https://dev.mysql.com/downloads/mysql/ 这里选择的是5.5的版本: 步骤1: 步骤2: 步骤三: 步骤四: 步骤5: 步骤6: 步骤7: 步骤8: 步骤 ...
- 前端最佳实践——DOM操作
1.浏览器渲染原理 在讲DOM操作的最佳性能实践之前,先介绍下浏览器的基本渲染原理. 分为以下四个步骤: 解析HTML(HTML Parser) 构建DOM树(DOM Tree) 渲染树构建(Rend ...
- vue引入ElementUI库
element国内网站:https://element.eleme.cn/#/zh-CN 引入ElementUI命令:npm install element-ui --save (网速不好用cnp ...
- JS基础语法---String对象下的方法（字符串的方法）
实例方法---->必须要通过new的方式创建的对象(实例对象)来调用的方法 静态方法---->直接通过大写的构造函数的名字调用的方法(直接通过大写的对象名字调用的) 字符串的常用属性: . ...
- mysql实践：sql优化
---恢复内容开始--- 设计表的时候 1. 不同的表涉及同一个公共意义字段不要使用不同的数据类型(可能导致索引不可用,查询结果有偏差) 2. 不要一张表放太多的数据 主表20~30个字段 ...