Managing RAID on Linux - Derek Vadala [37]
md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
linear personality registered
raid0 personality registered
raid1 personality registered
raid5 personality registered
If your system boots faster than you can read the messages, use the dmesg command to examine boot messages after the system has initialized. dmesg displays the kernel ring buffer, allowing users to examine important kernel messages that they might have missed during kernel initialization. The kernel ring buffer stores, in memory, messages about the current state of the running kernel. Some distributions are already preconfigured to dump these messages to a file after the system boots, but you can simply redirect the output to a file (dmesg > boot.messages) or pipe it into a pager (dmesg | less) at your whim. Messages returned by dmesg might look a little bit different from their appearance while the system is booting, but the same information is there:
# dmesg | grep md
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
md: multipath personality registered as nr 7
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
When the md driver initializes, its version is displayed (0.90.0, in this case). MAX_MD_DEVS indicates that the number of RAID devices is limited to 256 (with devices files named /dev/md[0-255]), and MD_SB_DISKS indicates that each software array is limited to 27 member disks. However, by building hybrid arrays, users can move well beyond this limit. Hardware limitations will become an issue long before you reach the limits of the md driver.
The kernel also registers each RAID level, or personality. In this case, the kernel contains support for linear mode, RAID-0, RAID-1, and RAID-4/5. If RAID support was compiled as loadable kernel modules, these initialization messages will not appear, but you should see them later in your system logs when those modules are inserted. These messages will be reported (like all md driver messages), using the kern facility, starting at the info level.
Please note that as the system remains running, the kernel ring buffer will begin to expunge old messages. So be certain to examine it soon after booting if you need to view information generated by the boot process. Most distributions are also preconfigured to place this information in /var/log/messages after the system boots. Please be aware that some distributions also come configured with an /etc/syslogd.conf that generates a misnamed file called /var/log/boot.log, using the log facility local7. This file (and any files generated using local7) contains messages from system initialization scripts (rc), not kernel initialization messages. Kernel messages are captured by klogd and dumped to syslogd once klogd has executed. In most default configurations, you will find messages about the md driver in /var/log/messages, including those dumped from the kernel ring buffer by klogd. Chapter 7 covers system logging and the md driver in further detail.
If RAID-5 is supported, the kernel will also optimize the XOR routines used for parity checksum in a RAID-5. A message indicating that the test was performed is displayed, along with its results:
raid5: measuring checksumming speed
8regs : 1835.600 MB/sec
32regs : 871.600 MB/sec
pIII_sse : 2021.200 MB/sec
pII_mmx : 2277.200 MB/sec
p5_mmx : 2386.000 MB/sec
raid5: using function: pIII_sse (2021.200 MB/sec)
Since different i386-based processor architectures implement different ways to perform the necessary XOR operations, Linux needs to determine which one is the most efficient for a particular system in advance. Notice that in this example, the fastest checksum operation was not chosen. On systems that support Streaming SIMD Extensions (SSE), that choice is selected because of its ability to circumvent the L2 cache and perform operations