Shulou(Shulou.com)06/01 Report--

Every time in building an OracleRAC environment, the most problems encountered are about ASM disks. By looking at many documents about building RAC on the Internet, we found that Oracle10g RAC people generally modify / etc/udev/rules.d/60-raw.rules, while some RAC building Oracle11R2, everyone is configuring / etc/udev/rules.d/99-oracle-asmdevices.rules this file, in the face of such a situation, I do not quite understand The difference between these two files has been bothering me for a long time, until today: using udev to manage asmdisk execution / sbin/scsi_id does not show UUID. Only by querying the relevant information can we have a deeper understanding of this problem.

The Linux platform converts block devices into character devices through udev, and fix the permissions and owners of the devices. This requirement is only needed when installing RAC databases before 11gR1. RAC,ASM with 11gR2 can use block devices directly. In addition to converting block devices to character devices, udev can also be used to fix device file names.

After that, the conclusion is verified by experiments.

For detailed steps, please refer to my other blog post:

Use udev to manage asmdisk execution / sbin/scsi_id does not display UUID

Catalogue

A brief introduction to udev. 1

Second, the advantages of udev. 2

2.1 dynamic Management. 2

2.2 Custom naming rules. 2

2.3 set permissions and owners / groups for the device. 2

The flowchart below shows udev's process of adding / removing device files. ... 3

Configure and use udev (CentOS6.4). 4

3.1 check the version and operation of udev in CentOS6.5. 4

3.2 configuration file for udev. 4

3.3 set permissions for device files through udev. 5

3.4 rules and rules files for udev. 5

4. Examples of formulating udev rules and querying equipment information. 8

4.1Lookup the information (attributes) of the device to make udev rules. 8

4.2 simple rules for udev. 10

4.3 other commonly used udev commands. 11

A brief introduction to udev

Udev is a function in the Linux2.6 kernel, which replaces the original devfs and becomes the default device management tool of Linux. Udev runs as a daemon and manages the device files in the / dev directory by listening for the uevent sent by the kernel. Unlike previous device management tools, udev runs in user space (userspace), not kernel space (kernel space).

II. Advantages of udev 2.1 dynamic management

When devices are added / removed, udev's daemon listens for uevent from the kernel to add or remove device files under / dev, so udev only generates device files for connected devices, not a large number of empty device files under / dev.

2.2 Custom naming rules

Through Linux's default rule file, udev defines kernel device names for all devices in / dev/, such as / dev/sda, / dev/hda, / dev/fd, and so on. Because udev runs in user space (user space), Linux users can flexibly generate highly identifiable device file names, such as / dev/boot_disk, / dev/root_disk, / dev/color_printer, and so on, through custom rule files.

2.3 set permissions and owners / groups for the device

Udev can set the permissions and owner / group of device files according to certain conditions. The approach to implementation is different in different versions of udev.

The flowchart below shows udev's process of adding / removing device files.

PS:

1. Device files: because this article explains udev in a more popular way, device files generally refer to files that can be used by applications to interact with device drivers under / dev/. There is no special distinction between device files, device nodes or device special files.

2.sysfs:sysfs is a virtual file system (/ sys) in the Linux2.6 kernel. It exports device and driver information from the device module of the kernel to user space (userspace). From this file system, Linux users can get the properties of many devices.

3.devpath: the devpath in this article refers to the relative path of a device under the sysfs file system (/ sys), which contains the properties file of the device. Most commands in udev operate on devpath. For example, the devpath for sda is / block/sda,sda2 and the devpath is / block/sda/sda2.

4. Kernel device name: the name of the device in sysfs, which is the device file name used by udev by default.

Configure and use udev (CentOS6.4) 3.1 to check the version and operation of udev in CentOS6.5

[root@testboot] # rpm-qa | grep-I udev

Udev-147-2.46.el6.x86_64

Libgudev1-147-2.46.el6.x86_64

Python-gudev-147.1-4.el6_0.1.x86_64

Libudev-147-2.46.el6.x86_64

System-config-printer-udev-1.1.16-23.el6.x86_64

[root@testboot] # ps-ef | grep-I udev

Root 27957 10 10:23? 00:00:00 / sbin/udevd-d

Root 28584 27957 0 10:34? 00:00:00 / sbin/udevd-d

Root 29017 1955 0 13:28 pts/0 00:00:00 grep-I udev

3.2Profiles for udev

[root@test~] # cat/etc/udev/udev.conf

# The initial syslog (3) priority: "err", "info", "debug" or its

# numerical equivalent. For runtime debugging, the daemons internal

# state can be changed with: "udevadm control--log-priority=".

Udev_log= "err"

The level at which udev_log:syslog logs, and the default value is err. If changed to info or debug, lengthy udev logs will be recorded.

In fact, in CentOS, in addition to the parameter udev_log listed in the configuration file, Linux users can also modify the parameters udev_root and udev_rules, but these two parameters are not recommended, so they are not shown in the udev.conf. Syslog logs udev by default, and Linux users can only modify the log level (err, info, degub, etc.). The permissions of the device cannot be set in udev.conf, but in the rules file (* .rules).

3.3.Setting permissions for device files through udev

In the udev of CentOS6.4, there are no permissions files, and all permissions are set through the rules file (* .rules), which is described in the rule file configuration process below.

3.4 rules and rules files for udev

The rules file is the most important part of udev and is stored under / etc/udev/rules.d/ by default. All rule files must have the suffix ".rules". CentOS has default rule files that generate not only kernel device names for devices, but also highly identifiable symbolic links. For example:

[root@test~] # ls/dev/disk/by-uuid/

18f9b7a4-f6a9-4a87-a63b-2660b12c87db 8ac6170e-8e4d-4385-a166-92c2aaeb75ca

5e2405ac-1cb5-4a90-a6c9-67c2c245667b c42b1176-beaf-4e52-98e3-1b6d386908c0

However, these link names are long and not easy to call, so custom rule files are usually needed to produce easy-to-use and highly identifiable device files or symbolic links.

Udev queries all rule files in alphabetical order of the rule file name, and then manages its device files or file links for devices that match the rules. Although udev does not stop parsing subsequent rule files because a device matches a rule, the order of parsing is still important. In general, it is recommended that the rule file you want be parsed first. For example, create a file called / etc/udev/rules.d/10-myrule.rules and write your rules to it so that udev will parse to your file before parsing the system's default rule file.

In a rule file, all non-blank lines are treated as a rule, except for lines that begin with "#" (comments), but a rule cannot be extended to multiple lines. Rules are composed of multiple key-value pairs (key-valuepairs) separated by commas. Key-value pairs can be divided into conditional matching key-value pairs (hereinafter referred to as "matching key") and assignment key pairs (hereinafter referred to as "assignment key"). A rule can have multiple matching keys and multiple assignment keys. The matching key is all the conditions that match all the attributes of a device. When the attribute of a device matches all the matching keys in the rule, the rule is considered to be effective, and then the assignment of the rule is performed according to the content of the assignment key. Here is a simple rule:

KERNEL== "sda", NAME= "my_root_disk", MODE= "0660"

KERNEL is the matching key, and NAME and MODE are the assignment keys. This rule means that if there is a device whose kernel device name is sda, the condition takes effect, performing the following assignment: generate a device file named my_root_disk under / dev and set the permissions of the device file to 0660.

It is a match key only if the operator is "= =" or "!"; if it is any other operator, it is an assignment key.

All operators of the udev rule:

"=": compare keys and values. If equal, the condition is satisfied.

"! =": compare keys and values. If not, the condition is satisfied.

"=": assign a key to it

"+ =": assign a value to a key that represents multiple entries.

": =": assign a value to a key and reject all subsequent changes to that key. The goal is to prevent subsequent rule files from assigning values to the key.

Match key for udev rule:

ACTION: the behavior of the event (uevent), for example: add (add device), remove (delete device).

KERNEL: kernel device name, for example: sda,cdrom.

DEVPATH: the devpath path of the device.

SUBSYSTEM: the subsystem name of the device, for example: the subsystem of sda is block.

BUS: the bus name of the device in devpath, for example: usb.

DRIVER: the device driver name of the device in devpath, for example: ide-cdrom.

ID: the identification number of the device in devpath.

SYSFS {filename}: the contents of the device's properties file "filename" under the device's devpath path.

For example: SYSFS {model} = = "ST936701SS" indicates that if the model of the device is ST936701SS, the device matches the match key.

In a rule, you can set up to five matching keys for SYSFS.

ENV {key}: environment variable. In a rule, you can set up to five matching keys for environment variables.

PROGRAM: invokes external commands.

RESULT: the result returned by the external command PROGRAM. For example:

PROGRAM== "/ lib/udev/scsi_id-g-s $devpath", RESULT== "35000c50000a7ef67"

Call the external command / lib/udev/scsi_id to query the SCSIID of the device, and if the return result is 35000c50000a7ef67, the device matches the match key.

Important assignment keys for udev:

NAME: the device file name generated under / dev. Only the first assignment to the NAME of a device takes effect, and then the matching rules and then the NAME assignment to the device will be ignored. If there is no rule to assign a value to the device's NAME, udev will use the kernel device name to generate the device file.

SYMLINK: generate symbolic links for device files under / dev/. Because udev can generate only one device file for a device, symbolic links are recommended in order not to overwrite files generated by the system's default udev rules.

OWNER, GROUP, MODE: set permissions for the device.

ENV {key}: import an environment variable.

The value of udev and the callable replacement operator:

The keys and operators in the key-value pair are all introduced, and finally the value (value). Linux users are free to customize the values of the udev rule file. For example: my_root_disk,my_printer. You can also reference the following replacement operator:

$kernel,% k: the kernel device name of the device, for example: sda, cdrom.

$number,% n: the kernel number of the device, for example: the kernel number of sda3 is 3.

$devpath,% p: the devpath path of the device.

$id,% b: the ID number of the device in devpath.

$sysfs {file},% s {file}: the contents of the file in the sysfs of the device. It is actually the property value of the device. For example: $sysfs {size} indicates the size of the device (disk).

$env {key},% E {key}: the value of an environment variable.

$major,% M: major number of the device.

$minor% m: minor number of the device.

$result, the result returned by% c:PROGRAM.

$parent,% P: the device file name of the parent device.

$root, the value of% r:udev_root, defaults to / dev/.

$tempnode,% N: temporary device name.

%%: symbol% itself.

$: symbol $itself.

KERNEL== "sd*", PROGRAM= "/ lib/udev/scsi_id-g-s% p",\ RESULT== "35000c50000a7ef67", SYMLINK= "% knot% c"

Execution of this rule: if a kernel device name begins with sd and SCSI ID is 35000c50000a7ef67, a symbolic link "sda_35000c50000a7ef67" is generated for the device file.

An example of making udev rules and querying device information 4.1 look up the information (attributes) of the device to formulate udev rules

When we set rules for a specified device, we first need to know the properties of the device, such as the serial number of the device, disk size, vendor ID, device path, and so on. Usually we can get it in the following ways:

Query the sysfs file system:

As mentioned earlier, sysfs contains a lot of information about devices and drivers.

For example, the SYSFS {size} of the device sda can be obtained through cat/sys/block/sda/size, and the SYSFS {model} information can be obtained through cat/sys/block/sda/device/model.

Udevadm info command: (Centos5.3 is udevinfo command)

Udevadm info can query the equipment information in udev database. For example, use udevadm info to query the model and size information of the device sda:

[root@test~] # udevadm info-a-p / sys/block/sda | egrep "model | size"

ATTR {size} = "62914560"

ATTRS {model} = = "VBOX HARDDISK"

[root@test~] # udevadm info-a-p / sys/block/sda

Udevadminfo starts with the device specified by the devpath and then

Walksup the chain of parent devices. It prints for every device

Found,all possible attributes in the udev rules key format.

Arule to match, can be composed by the attributes of the device

Andthe attributes from one single parent device.

Looking at device'/devices/pci0000:00/0000:00:0d.0/host2/target2:0:0/2:0:0:0/block/sda':

KERNEL== "sda"

SUBSYSTEM== "block"

DRIVER== ""

ATTR {range} = = "16"

ATTR {ext_range} = = "256"

ATTR {removable} = = "0"

ATTR {ro} = = "0"

ATTR {size} = "62914560"

ATTR {alignment_offset} = = "0"

ATTR {discard_alignment} = = "0"

ATTR {capability} = "52"

ATTR {stat} = "30322 6547 1191594 333118 7382 94590 811468 137604 0154932 470661"

ATTR {inflight} = = "0"

Looking at parent device'/devices/pci0000:00/0000:00:0d.0/host2/target2:0:0/2:0:0:0':

KERNELS== "2VOV 0VOUR 0UR 0"

SUBSYSTEMS== "scsi"

DRIVERS== "sd"

ATTRS {device_blocked} = = "0"

ATTRS {type} = = "0"

ATTRS {scsi_level} = = "6"

ATTRS {vendor} = = "ATA"

ATTRS {model} = = "VBOX HARDDISK"

ATTRS {rev} = = "1.0"

ATTRS {state} = = "running"

ATTRS {timeout} = = "30"

ATTRS {iocounterbits} = "32"

ATTRS {iorequest_cnt} = = "0x95a8"

ATTRS {iodone_cnt} = = "0x957d"

ATTRS {ioerr_cnt} = = "0x5"

ATTRS {modalias} = = "scsi:t-0x00"

ATTRS {evt_media_change} = = "0"

ATTRS {dh_state} = = "detached"

ATTRS {queue_depth} = "31"

ATTRS {queue_ramp_up_period} = "120000"

ATTRS {queue_type} = = "simple"

Looking at parent device'/devices/pci0000:00/0000:00:0d.0/host2/target2:0:0':

KERNELS== "target2:0:0"

SUBSYSTEMS== "scsi"

DRIVERS== ""

Looking at parent device'/devices/pci0000:00/0000:00:0d.0/host2':

KERNELS== "host2"

SUBSYSTEMS== "scsi"

DRIVERS== ""

Looking at parent device'/devices/pci0000:00/0000:00:0d.0':

KERNELS== "0000:00:0d.0"

SUBSYSTEMS== "pci"

DRIVERS== "ahci"

ATTRS {vendor} = = "0x8086"

ATTRS {device} = = "0x2829"

ATTRS {subsystem_vendor} = = "0x0000"

ATTRS {subsystem_device} = = "0x0000"

ATTRS {class} = = "0x010601"

ATTRS {irq} = "21"

ATTRS {local_cpus} = = "1"

ATTRS {local_cpulist} = = "0"

ATTRS {modalias} = = "pci:v00008086d00002829sv00000000sd00000000bc01sc06i01"

ATTRS {numa_node} = "- 1"

ATTRS {enable} = = "1"

ATTRS {broken_parity_status} = = "0"

ATTRS {msi_bus} = ""

Looking at parent device'/ devices/pci0000:00':

KERNELS== "pci0000:00"

SUBSYSTEMS== ""

DRIVERS== ""

4.2 simple rules for udev

Rules for generating network card device files:

SUBSYSTEM== "net", SYSFS {address} = = "AA:BB:CC:DD:EE:FF", NAME= "public_NIC"

The rule states that if there is a device whose subsystem is net and the address (MACaddress) is "AA:BB:CC:DD:EE:FF", a device file named public_NIC is generated for the device.

Rules for generating symbolic links for disks of a specified size

SUBSYSTEM== "block", SYSFS {size} = = "71096640", SYMLINK = "my_disk"

The rule states that if there is a device whose subsystem is block and the size is 71096640 (block), a symbolic link named my_disk is generated for the device file name of the device.

Rules for generating device files for disks with specified serial numbers through external commands

KERNEL== "sd* [0-9]", PROGRAM== "/ lib/udev/scsi_id-g-s% p",\ RESULT== "35000c50000a7ef67", NAME + = "root_disk%n"

The rule states that if there is a device whose kernel device name starts with sd (disk device) and ends with a number (disk partition), and the SCSI_ID number of the device is queried as "35000c50000a7ef67" through an external command, a device file that begins with root_disk and ends with the kernel number is generated, and the original device file is replaced (if any). For example: generate the device name / dev/root_disk2 and replace the original device name / dev/sda2.

Using this rule, you can maintain the consistency of the system partition name in / etc/fstab without being affected by the driver loading sequence or disk label being broken, resulting in the system partition not being found when the operating system boots.

4.3 other commonly used udev commands

Udevadm test (subcommand of udevadm): simulates a run of udev without uevent trigger for a device, and outputs the process of querying the rule file, the behavior executed, and the execution result of the rule file.

Simulate a udevevent run for the given device, and print debugoutput

The start_udev:start_dev command restarts the udev daemon and re-queries all the rule files in the rules directory for all devices, and then executes the behavior in the matching rules. You usually use this command to make the new rule file take effect immediately:

[root@test~] # start_udev

Startingudev: [OK]

Start_udev generally has no standard output, and all udev-related information is set according to the parameters of the configuration file (udev.conf) and recorded by syslog.

Author: SEian.G (hard practice changes in 72, but it is difficult to laugh at 81)

ITPUB: http://blog.itpub.net/31015730/

51CTO: http://seiang.blog.51cto.com/

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.