• Choose a category
• All
• Classic-Fiction

The mkfs.xfs command is used to create a new filesystem; the -b flag specifies the block size of the new filesystem.

# mkfs.xfs -b size=4k /dev/md0

This command creates a new filesystem on /dev/md0, with a block size of 4 KB. XFS supports block sizes ranging from 512 bytes to 64 KB in power-of-2 increments. However, the current implementation allows only a block size less than or equal to the page size of the resident system. That means 4 KB or less on 32-bit systems (i386, PowerPC) and 8 KB or less on 64-bit systems (Alpha, SPARC, IA64). By default, mkfs.xfs creates a filesystem using a block size equal to page size.

Further Information

For more information about XFS, please refer to the project's web site at http://oss.sgi.com/projects/xfs/. I'd specifically like to point out both the FAQ (http://oss.sgi.com/projects/xfs/faq.html) and mailing list (http://oss.sgi.com/projects/xfs/mail.html) as excellent sources of up-to-date information.

Chapter 7. Performance, Tuning, and Maintenance

Keeping a system running, and running well, should be the desire of every system administrator worth their salt. This chapter covers a variety of topics related to this goal:

Monitoring RAID devices

Tuning hard disks

Performance testing

Installing directly to a software RAID

Monitoring RAID Devices

Monitoring is an essential part of working with RAID. Since most arrays can survive only a single disk failure, it's important to know when any failure occurs. That way, failed disks can be replaced before a second disk fails and causes data loss. The easiest way to monitor arrays is by modifying your existing scripts and monitoring platforms to look for information about the RAID subsystem in your system logs. You can look for keywords such as md, raid1, recovery, resyncing, raid5, raid0, linear, RAID, and superblock. It's a good idea to take a look at the information that the RAID subsystem reports to syslog so that you can get a good idea of how to custom-tailor monitoring for your specific needs.

RAID and syslog

The md driver uses the system logging daemon (syslogd) to report pertinent information and errors relating to the kernel RAID subsystem. md reports information using the kern facility (LOG_KERN). Table 7-1 outlines the priorities at which the RAID subsystem reports information to the kernel ring buffer.

Table 7-1. Software RAID log reporting

facility.priority

Information reported

kern.info

Status changes, including insertion and removal of member disks, resynchronization progress, and startup and shutdown notices. In general, any information about an array that does not affect performance or continuing operation.

kern.err

Error messages about problems that either prevent an array from being started, created, or modified, or affect array operation in a nonfatal manner. This includes disk failures and consequent insertion of spare disks, initialization and completion of reconstruction, and problems with the configuration file.

kern.alert

Catastrophic errors that prevent a running array from continuing to operate. Problems logged at this level usually result in the crash of a running array or the inability to start an array that is not running. These issues include memory problems, low-level device problems, and fatal errors that occur during the reconstruction process.

Many distributions log this information to some combination of /var/log/messages and /var/log/warn. The following line in /etc/syslog.conf captures all kernel-level messages:

kern.* /var/log/kernel

After adding this line, be certain to restart syslogd. You should also touch the file /var/log/kernel, as well as any new files you reference in /etc/syslogd.conf, if they do not already exist:

# touch /var/log/kernel

# kill -HUP `/var/run/syslogd.pid`

Since a lot of information is reported using the kern facility, it's a good idea to tune /etc/syslog.conf to meet specific system needs. On high-volume