| Sun Blade X6440 Server Module Operating System Installation Guide |     |
| C H A P T E R 7 |
|
Installing and Booting an Operating System on Compact Flash |
This chapter contains an overview on using a compact flash (CF) card as a bootable device, and covers the advantages and disadvantages of using a CF for booting an operating system (OS). It also contains procedures for prolonging the life span of your CF card through optimization. The Solaris, OpenSolaris, and Linux operating systems support booting from CF. The procedures for optimizing each are slightly different.
This chapter contains the following sections:
Your Sun Blade X6440 server module can be equipped with an internal 8-GB (or 16-GB) compact flash (CF) card, which you can use to install and boot supported versions of the Solaris, OpenSolaris, or Linux operating system.
As a boot device, the main advantages of CF card over a hard drive are its very low power consumption, its fast read speeds, and its size. A CF card requires no power to maintain its data, because it is solid-state non-volatile memory. It has no moving parts, no seek time, no latency period, and no spin-up. Compared to a hard drive, both the time required to read and write and the total package size of a CF card are significantly reduced. Therefore, CF offers improved power and cooling, performance, and space efficiencies.
The disadvantage of CF is its limited life span. The card’s life span is dependent upon the number of write/erase cycles it receives. A block of memory on a CF card can only sustain a limited number of write/erase cycles before it degrades and the card becomes unusable (reading does not degrade CF). In this respect, an OS can place a high demand on a CF card, because it performs many write-intensive tasks such as logging and swapping.
You can significantly prolong the useful life of a CF card by configuring the OS to redirect and relocate the more write-intensive tasks off the CF card on to other devices, such as an external hard drive or RAM. Specifically, some of the things you can do to reduce write/erase cycles include:
The above options are discussed in the following Linux, Solaris, and OpenSolaris OS-specific sections:
The procedures in this section detail how to prolong CF life span by reducing OS write/erase cycles. After you have installed an OS to the Sun Blade X6440 server module’s CF card, it is recommended that you implement as many of the following procedures as possible:
This section contains two procedures that you can use to redirect log output off the CF card. These procedures will help to reduce OS write/erase cycles and prolong the life span of the CF card:
This procedure details how to mount /var over NFS at boot time to redirect system log output off the CF card and onto an NFS share drive. Performing this procedure reduces the OS write/erase cycles and prolongs the life span of the CF card.
| Note - If you have multiple servers logging to the NFS server, each server should have a separate directory. This will reduce file-locking related problems and simplify log analysis. |
1. To mount /var over NFS at boot time, add the following entry to the /etc/fstab file:
server:/path/to/dir /var nfs sync 0 0
2. Save and close the /etc/fstab file.
You will now need to make an entry in the /etc/exports file on the log server to authorize the client to mount and write to the share.
3. To authorize the client to mount and write to the share drive, add the following entry to the /etc/exports file on the log server:
/path/to/logs/client host_name client_IP(rw,no_root_squash,no_subtree_check)
4. Save and close the /etc/exports file.
Since you made changes to the /etc/exports file, you should now refresh the NFS server.
5. To refresh the NFS server, type the following command:
This procedure details how to redirect system log output from the CF card and over the network using syslog. Performing this procedure reduces the OS write/erase cycles and prolongs the life span of the CF card.
| Tip - You might also want to implement firewall rules to restrict which hosts are allowed to log output to your log server. |
| Note - The remote log server must have syslogd running with the -r flag. |
To configure syslogd to log to a remote server edit the /etc/syslog.conf file by performing the following modification:
Change:
kern.*; /var/log/messages
The above modification redirects all kernel related messages from the /var/log/messages directory to host.domain.com. The following is an example of a sample /etc/syslog.conf file that sends messages to a remote system:
The above sample sends all log messages to host.domain.com. Additionally, the following line saves a copy of error and emergency level messages:
*.err;*.emerg /var/log/messages
To tune your system even further comment out this line. Comment lines are preceded by the # character:
# *.err;*.emerg /var/log/messages
| Tip - Since many daemons can be configured to redirect their logging output to syslog, you can tune your system further by redirecting many of the other log files that are generated on your system. |
| Note - If you receive errors when trying to log output to a remote server, ensure that your Linux distribution has started syslog after the network was brought up. |
This procedure details how to mount /tmp as a tmpfs RAM disk. Performing this procedure reduces the OS write/erase cycles and prolongs the life span of the CF card.
|
Caution - A RAM disk uses volatile memory. Information stored in a RAM disk will not survive a reboot or power outage. Additionally, RAM disks decrease the total available memory. |
1. Determine the size of the tmpfs RAM disk partition.
You should make this determination based upon the memory needs of your system.
100 MB is used in the example in this procedure. This value is set with the size parameter. Acceptable suffixes are K, M, or G (kilo, mega, and giga, respectively). See the tmpfs man page for information about other configuration options.
2. To mount /tmp as a 100 MB tmpfs partition, run the following command:
% mount -t tmpfs -o size=100M,nr_inodes=1k,mode=777 tmpfs /tmp
To automate the above mount, add the following entry to the /etc/fstab file:
none /tmp tmpfs auto,size=100M,nr_inodes=1k,mode=777 0 0
The procedures detailed in this section show how to manage system swap so that it does not occur on the CF card. Performing this procedure reduces the OS write/erase cycles to and prolongs the life span of the CF card.
The options for managing swap are:
Running your system without swap is not an optimal solution. However, swapping on CF is not advisable either. Swap space, while not a requirement, does provide a buffer zone to guard against transient problems with inadequate resources.
The key to running without swap is to understand the memory requirements of your applications and plan your system based on these requirements. If you have enough RAM to satisfy your server’s projected need for temporary storage then you do not need swap.
If you have external storage, you can use a partition on that hard drive for swap space. If the hard drive you want to swap on is attached to the system, you can configure swap space during installation process. If you did not configure swap during the installation process, see Configuring Swap on External Storage Post-Installation.
If you would like to configure swap post-installation, you will need to do the following:
3. Add an entry in the /etc/fstab file.
| Note - Swapping from a disk that you also use for data storage can increase the number of seeks that disk performs and therefore increase latency for that disk. |
| Note - This procedure assumes that you are starting from a blank disk. |
1. Create a partition with the following command:
% parted /dev/device_name mkpart primary Linux-swap 0 X
| Note - The general rule of thumb is that swap space should be 2 times your RAM size. |
2. Edit the /etc/fstab file to add the new swap device:
/dev/device_name swap swap defaults 0 0
3. Reboot the system, or to start swapping without waiting for a reboot, enter the following command:
The Solaris OS or OpenSolaris allows the administrator to configure a swap device during installation. If the root disk of the OS is on CF, then swap should be disabled, or moved to a hard drive or RAM.
If this is a new machine, then relocate or disable swap. If the machine is already installed, you can disable swap by removing the swap device entry from the vfstab file or by using the swap command.
1. (If necessary) To identify swap devices, enter the following command:
The command returns the current swap device. For example:
Where: device_name is the name of the device used for swap.
2. Open the vfstab file in an editor, and locate the swap entry line.
The file is divided into seven fields. The swap entry line will have your swap device listed in the first field and swap listed in the fourth field. For example:
/dev/dsk/device_name - - swap - no -
3. Edit the vfstab file by changing the swap entry to a comment.
To change an entry to a comment, type the # character at the beginning of the entry line. For example, the following swap entry line has been changed to a comment:
# /dev/dsk/device_name - - swap - no -
5. For the changes to take effect, reboot, or, if you do not want to reboot, use the following mount command:
Refer to the mount man page for a description of options.
Refer to the swap man page before entering this command.
Where: swap_name is the name of the swap file.
By default, the Solaris OS or OpenSolaris OS uses the swap device as a source for kernel crash dumps. When the swap device is disabled, the swap partition is configured as a dedicated dump device. This is unsuitable for most purposes, because you want to minimize writes to the CF card. If you would like to capture crash dumps, use the following procedure to configure a different dedicated dump device.
To configure a device as a dump device, enter the following command:
# dumpadm -c kernel -d /dev/dsk/device_name
Where: device_name is the name of the device to configure as a dump device.
By moving temporary files to RAM, you can further reduce I/O to the CF card. By default the Solaris OS or OpenSolaris OS /tmp filesystem is mounted using tmpfs, essentially a RAM disk. By moving /var/temp to tmpfs, you can eliminate the majority of temporary files from being written to the root disk. You can do this manually, or you can move /var/temp to tmpfs by editing the vfstab file.
1. Add the following entry to the /etc/vfstab file:
swap - /tmp tmpfs - yes -
swap - /var/tmp tmpfs - yes -
TABLE 7-1 shows an example of this entry.
| Note - To manually move /var/tmp to tmpfs, use the mount command:
% mount -F tmpfs swap/var/tmp |
3. For the changes to take effect, reboot, or, if you do not want to reboot, use the following mount command:
Refer to the mount man page for a description of options.
UNIX filesystems are required to update file metadata each time a file is accessed. Even if the file has been read, but not written, the OS will still update the access time (or atime). UFS and ZFS filesystems allow you to disable updates to the file access times. For ZFS, you use the set command. For UFS, you configure the noatime option in the vfstab file. Additionally, UFS offers the option to defer atime writes (dfratime) until the disk is accessed for a reason other than updating access times. This option is set by default. For more information, see the mount_ufs man page.
| Note - Disabling file atime may result in unpredictable behavior with some applications that depend on atime updates to function properly. |
To disable atime updates under ZFS, enter the following command:
zfs set atime=off filesystem_name
Where: filesystem_name is the name of the filesystem to disable atime.
1. To disable atime updates under UFS, edit the /etc/vfstab file by adding the noatime mount option to the appropriate entry.
TABLE 7-2 shows an example of this entry.
2. Save and exit the /etc/vfstab file.
3. For the changes to take effect, reboot, or, if you do not want to reboot, use the following mount command:
Refer to the mount man page for a description of options.
You can configure the syslog daemon to send its log messages to a remote host. To do this, you must edit the syslogd.conf file to change the destination for log messages to @loghost or @hostaname. If loghost is used, it maps to localhost in the hosts database by default. Be sure to change the loghost entry in /etc/hosts to point to the correct machine. The syslog.conf man page contains additional details about remote logging.
| Tip - If you have a machine configured to receive log messages for other hosts, consider allowing the machine with the root CF device log to this remote host. |
1. Edit the syslog.conf file and redirect /var/adm/messages to @loghost or @hostname.
CODE EXAMPLE 7-1 shows a sample syslog.conf file. In this sample, the original entry is changed to a comment, by affixing the # character to the beginning of the entry, and the new entry has been added beneath it:
#*.err;kern.debug;daemon.notice;mail.crit /var/adm/messages
*.err;kern.debug;daemon.notice;mail.crit @loghost
2. Save and exit the syslog.conf file.
3. If necessary, define loghost by editing the /etc/hosts file.
Since the example above uses loghost, it needs to be defined in the /etc/hosts file. You define loghost using the IP address of the log machine, indicating where the OS should send the messages. The following example is an excerpt from the /etc/hosts file that has modified localhost so that it is no longer loghost:
4. Save and exit the /etc/hosts file.
| Sun Blade X6440 Server Module Operating System Installation Guide | 820-3962-11 | |
Copyright © 2009 Sun Microsystems, Inc. All rights reserved.
To Redirect Log Output to an NFS Share