4    Disk Space Planning

This chapter contains information about the standard UNIX file systems and provides disk space planning guidelines should it be necessary for you to manually plan disk space. The Full Installation process has built-in automatic disk space planning features, so it is unlikely that you would have to manually plan disk space.

Topics in this chapter include:

Note

Refer to the Glossary in the Installation Guide for definitions of the terms used in this chapter.

4.1    Overview of File Systems and Disk Space

A Full Installation of the operating system creates several basic UNIX file systems: / (root), /usr, and one area for swap space. The var area can be a directory under the /usr file system, or it can be created as its own file system. The Full Installation process is designed to simplify your decision making with respect to where to place these file systems on a disk and how big they have to be in order to install the operating system. This chapter describes the built-in disk planning features of the Full Installation and then gives you the information you need to know if your computing environment requires a more customized approach.

4.2    Disk Planning Considerations for Clusters

The information in this chapter applies to disk planning for single system installations. Refer to the TruCluster Server Software Installation and Cluster Administration manuals for information about disk space planning considerations for cluster file systems, quorum disks, and general information about configuring systems as cluster members.

4.3    Overview of File System Types

This operating system supports two types of file systems, the Advanced File System (AdvFS) or the UNIX File System (UFS).

You can choose either AdvFS or UFS as the file system type for the /, /usr, /var, and /usr/i18n file systems. If you are customizing the file system layout, all file systems do not have to use the same file system type. If you are using the default file system layout, you only can use one file system type for all file systems.

The Logical Storage Manager (LSM) is available to install and configure for both file system types.

The information in this section is intended to aid you in making the decision with respect to which file system type to choose.

4.3.1    The Advanced File System (AdvFS)

AdvFS is the default file system type. If you plan to install a cluster, you must choose AdvFS as the file system type.

AdvFS is a log-based file system that provides flexibility, compatibility, data availability, high performance, and simplified system management. AdvFS takes advantage of the 64-bit computing environment and is designed to handle files and filesets as large as almost 16 terabytes.

The configuration of AdvFS differs from the traditional UNIX file system. In AdvFS, the physical storage layer is managed independently of the directory layer. System administrators can add and remove storage without unmounting the file system or halting the operating system. As a result, configuration planning is less complicated and more flexible.

From a user's perspective, AdvFS behaves like any other UNIX file system. End users can use the mkdir command to create new directories, the cd command to change directories, and the ls command to list directory contents. AdvFS logical structures, quota controls, and backup capabilities are based on traditional file system design.

Without taking an AdvFS system off line, system administrators can perform backups, reconfigure file systems, and tune file systems. End users can retrieve their own unintentionally deleted files from predefined trashcan directories or from clone filesets without assistance from system administrators.

AdvFS supports multivolume file systems, which enables file-level striping (spreading data to more than one volume) to improve file transfer rates for I/O intensive applications. Logical Storage Manager (LSM), which allows volume-level striping, can be incorporated into AdvFS configurations.

AdvFS Utilities, which are licensed separately from the operating system, provide additional file management capabilities and a graphical user interface (GUI) to simplify system administration. The AdvFS GUI, which runs under the Common Desktop Environment (CDE), features menus, graphical displays, and comprehensive online help that make it easy to perform AdvFS operations.

With the exception of the / file system, AdvFS file system size can be modified at any time (with the addvol command). Increases or decreases to file system size are transparent to the user.

If you plan to use AdvFS as the file system type and you install the optional AdvFS Utilities, which are available on a separate CD-ROM distribution and require a special license, modifying file system space is simplified. After the installation, the AdvFS utilities let you add or remove volumes from the AdvFS file systems with no changes to the directory structure and with no user interruption. There is no need to over allocate file system space for AdvFS file systems.

Refer to the AdvFS Administration guide if you need more information about AdvFS.

4.3.2    The UNIX File System (UFS)

UFS is the older, more traditional file system type for UNIX operating systems. Any operation on the disk is not as robust as AdvFS, however it is a standard file system type that offers stability and less chance of corrupting data. AdvFS can have files from one file system on more than one disk or partition, but UFS has a more rigid hierarchy. In a UFS file system, each disk or disk partition contains one separate file system; all files in a file system are located on one disk in the assigned disk partition. The UFS file system is characterized by a hierarchical structure, the ability to create and delete files, dynamic growth of files, and the protection of file data.

UFS is compatible with the Berkeley 4.3 Tahoe release. UFS allows a pathname component to be 255 bytes, with the fully qualified pathname length restriction of 1023 bytes. This implementation of UFS supports a maximum file size equivalent to the largest supported file system (128 GB).

Note

The Logical Storage Manager (LSM) can be used with the UFS file system type. Clusters cannot use the UFS file system type.

Refer to the System Administration guide for more information about UFS.

4.4    Automatic Disk Space Planning Features of the Full Installation

The Full Installation process provides the option to use a predefined default file system layout:

The design of the default file system layout along with the recommended disk partition table allows the entire operating system to fit on a single disk that is 1 GB or greater in size. If you are comfortable with these defaults and your system configuration does not have any special considerations, there is no reason to perform additional disk planning exercises. The details of a default file system layout are shown in Figure 4-1. This sample installation uses dsk1 as the single disk on which to install the operating system.

Figure 4-1:  Default File System Layout: Details Window

Section 4.5 describes the situations when you should consider manually planning the file system layout and disk partition sizes.

4.5    When Should I Manually Plan Disk Space?

There are certain circumstances when you should manually plan disk space rather than accepting the defaults or recommendations. It should only be necessary to plan disk space if any of the following is true:

4.5.1    Considerations for Remote Installation Services (RIS)

RIS is a utility that is used to set up a central server to serve software over the network to registered client systems. If you are planning to set up your system as a RIS server, you have the option to extract software subsets from the distribution media into the /var/adm/ris directory in the var area instead of using locally mounted media as the source of the RIS area. Extracting software takes up a considerable amount of disk space because you are copying the contents of the operating system CD-ROM onto the disk. You also may need to serve more than one version of the operating system, which requires the extraction and storage of yet more software subsets. One extracted RIS area for the base operating system requires approximately 600 MB of disk space. Disk space requirements for individual layered products are shown in the Release Notes.

Another option when using RIS is to create a symbolically linked RIS area. In this type of area, the total contents of the CD-ROM is not copied but is linked to the RIS area. The only disadvantage for a symbolically linked area is that the device holding the distribution media is now used exclusively for this purpose. As a guideline, you can assume a symbolically linked RIS area will take about 10 MB of space for the network bootable kernel and other support files.

You must reserve enough space in the /var/adm/ris directory in the var file system for the software you want to store in each RIS environment. How much space you reserve depends upon how many RIS environments you intend to create. Refer to the Installation Guide for a description of each software subset and the names of other subsets or kernel configuration file options related to RIS operation.

4.5.2    Considerations for Dataless Management Services (DMS)

In a Dataless Management Services (DMS) environment, a server system maintains the / and /usr file systems for all client systems. The server maintains one copy of / for each client. The /usr file system is exported read-only and is shared by all clients registered to the environment. Client systems have their own /var file system.

Each DMS environment is located in a /var/adm/dms/dmsn.alpha directory. Depending upon the server and client relationships at your site, you may have several n.alpha areas. Each area must have at least the base operating system mandatory subsets installed as well as other optional software subsets. Space must be reserved for associated or layered products plus an additional 10 percent for file system administration tasks and file system information. For more information about the size requirements of a dataless environment, refer to the guide to Sharing Software on a Local Area Network.

If you want the system to serve a dataless environment, you must decide whether you want /var on a separate file system or whether you want to reserve a partition to mount under /var/adm/dms.

You also should consider space requirements for the /clients directory, which holds the / file system for each dataless client. You can make the /clients directory a separate file system or keep it in the server's / file system in which case you should allocate 64 MB of space for each client.

4.6    Considerations for Customizing Disk Partitions and File System Layout

The following sections describe what you need to know if you want to create your own disk partition sizes or define a different file system layout. Information includes:

4.7    Determining Existing Disk and Partition Sizes

A system that is already running a previous version of the operating system may already have a customized disk partition table. To check the disk layout and partition sizes, you have to examine the existing disk label. A disk label contains information about the disk such as the disk type, physical parameters, and partition sizes. Without a disk label, a disk is not bootable.

From the text-based Full Installation interface, use the disklabel command to view the disk label as described in Chapter 3. Also refer to the disklabel(8) reference page for more information.

If you already have started a Full Installation with the graphical interface, view the current disk partition information by clicking on the Edit Partitions... button on the Custom File System Layout dialog box to open the Disk Configuration application. When the Disk Configuration is open, click on the Help menu to view the online help. Figure 4-2 shows a sample disk partition screen from the Disk Configuration application.

Figure 4-2:  Disk Configuration Application: Sample Disk Partition Information

Figure 4-3 shows a sample disk table screen from the Disk Configuration application.

Figure 4-3:  Disk Configuration Application: Sample Disk Table

4.8    How Much Disk Space Does the Software Require?

An important thing you need to know is how much disk space the software will consume. During a Full Installation you can obtain the amount of space you need in the /, /usr, and /var file systems in one of two ways:

This information helps you decide whether the disk partitions you chose are large enough to hold the software subsets you want to install. At any time you can change your disk and partition selections if the partitions are running out of space. As described in Section 4.8.1, file system overhead is included in file system space calculations.

Note

During a Full Installation, if the partition table on the disk chosen for the / file system varies from the recommended table, you have the option to use either the recommended disk partitions or your customized partitions.

Another manual way to determine software subset sizes is to look in the software subset size tables in the Release Notes.

4.8.1    File System Overhead

When calculating the available disk space for the /, /usr, and /var file systems, the Full Installation procedure uses approximations for file system overhead based on the file system type selected for each file system. During a Full Installation, the amount of disk space that is calculated during software subset selection includes these overhead requirements.

4.9    Contents of File Systems

The following sections describe the contents of the basic UNIX file systems and the special space considerations associated with them.

4.10    Contents of the /usr File System

The /usr directory contains the majority of the operating system files, including libraries, executable programs, and documentation. The directory structure contains directories such as /usr/sys, /usr/adm, and /usr/bin. These directories contain required system files and UNIX command binary files that require a considerable amount of space in the /usr file system.

To manually determine the size of the /usr file system, consider the following:

Over time, you will add files to the /usr file system, and future releases of the operating system may require more space as well. Because of this, the file system can run out of space. Be sure to allow for enough future growth on the /usr file system.

If you plan to use the Advanced File System (AdvFS) as the file system type and install the AdvFS Utilities (available with a separate license), you do not need to greatly over allocate space for the /usr file system. AdvFS file system space can be increased dynamically without changing directory structures and without system interruption. Refer to AdvFS Administration for more information about the AdvFS file system type.

Section 4.10.1 and Section 4.10.2 briefly describe how various items affect the size of the /usr file system and should be considered when planning disk space.

4.10.1    Space for Optional Software Subsets and Associated Products

The /usr file system must be large enough to accommodate the software subsets that will reside within it. A software subset is a collection of executable files and data files needed to perform a specific function or to provide a particular class of services; for example, you need the System Accounting Utilities software subset to perform system accounting.

The Installation Guide contains software subset descriptions along with the dependent software subsets and kernel configuration file options related to each software subset. The Release Notes contain tables of software subset sizes.

The mandatory software subsets are always installed. The optional software subsets are not required for the operating system to be fully functional; you can choose none, some, or all of the optional software subsets, depending on your requirements and available disk space.

For WLS installations, the size of the /usr/i18n directory must be considered if /usr/i18n is not created as a separate file system.

You may also want to allocate space for future installations of associated or layered products that are compatible with this version of the operating system. When planning disk space requirements for /usr, allow additional space if you will be adding products in the future. Refer to the associated product's Release Notes for the exact size of the software.

4.10.2    Space for User Accounts and Files

The Full Installation process does not provide an area for user accounts and files; you need to set up this area after the installation. However, you should consider the amount of space needed for user files when planning your system. If you plan to place users' home directories on /usr, you should reserve at least 10 to 20 MB of disk space for each user on the system. Multiply that figure by the number of users to get an approximate size of user's home directories.

Note

It is recommended that you create a separate file system (on another disk if one is available) for users' home directories and mount the new file system perhaps under the /usr file system. Placing users' home directories in another file system ensures that the directories will not be overwritten during future Full Installations. It also makes disaster recovery less complicated because you can reinstall the operating system without losing user accounts.

If you intend to set quotas on the user area, multiply the quota for each user by the number of users to determine the amount of user space. Refer to the System Administration guide for information on disk quotas.

4.11    Contents of the var File System

The /var area contains volatile, machine-specific directories and directories such as tmp and adm.

You can allocate the /var area either as a file system on its own partition or as a directory under the /usr file system. If system use is heavy, you might want to create a separate /var file system.

To determine the size of the /var area, consider the following:

If you plan to use AdvFS as the file system type for /var along with the AdvFS Utilities (available with a separate license), you do not need to greatly over allocate space for the /var file system. AdvFS file system space can be increased dynamically without changing directory structures and without system interruption. Refer to AdvFS Administration for more information about AdvFS.

4.11.1    Crash Dump Space in the var File System

Two disk areas are used when the system produces a crash dump. As described in Section 4.12, the first area is located in the swap partition and is used to hold the crash dump until the system is rebooted. This area must be large enough to hold a single crash dump.

The second area is where the savecore utility copies the crash dump and a copy of the kernel, /vmunix, when the system is rebooted. This area is located in the /var/adm/crash directory. The disk partition that contains /var/adm/crash must be at least large enough to hold one crash dump and one copy of /vmunix, which is 10 to 13 MB in size. The partition can be made as large as disk resources permit if you want to retain multiple crash dumps.

The crash dump partition must be as large as the size of physical memory on systems configured for full dumps, and can be somewhat smaller on systems configured for partial dumps.

If you want to retain multiple crash dumps, estimate the size of this partition by multiplying the total size required for a single crash dump and a copy of /vmunix by n, where n is the number of crash dumps to retain.

The System Administration guide contains a chapter devoted to managing crash dumps and crash dump files, which includes information about how crash dumps are written, choosing partial or full dumps, deciding how much space to reserve for both crash dumps and crash dump files, and much more.

To determine the size and to record the location of the crash dump space, provide the following information:

  1. The memory size in MB for your system is _________.

    If you do not know the amount of memory on your system, do one of the following:

  2. You need ________ memory to accommodate your crash dump partition.

4.11.2    Space for Error Logger and syslog Files

The /var area requires room to accommodate the log files produced by both syslog and the binary error logger. These log files are a record of system events and errors in ASCII text (syslog) and binary formats.

The syslog utility collects information regarding such system activities as mail, system start-up, shutdown, rebooting, root account logins, time daemon, printer subsystem, and syslog itself. Summary information on hardware errors is also logged. The amount of data logged is related to system activity and the number of users.

The binary error logger records information on hardware errors and system start-up.

If you are creating a new system, estimate your total requirements at about 500 kB per week. There is no limit to how large the /var/adm/binary.errlog and the /var/adm/syslog files can grow, so they eventually might fill their partition.

4.11.3    Space for System Accounting Files

The /var/adm directory contains data files generated by administrative programs such as acct and wtmp. The data that these programs generate can vary widely from system to system and over time. For example, if you create a /var/adm/acct file, it can grow by 50 kB a day for a large system and by 5 kB a day for a workstation.

As a general guideline for system accounting, you should allot 10 kB per day for workstations and 100 kB per day for larger systems. Refer to System Administration for more information on the space requirements for system accounting.

4.12    Swap Space Overview

Virtual memory is implemented in the operating system by transparently moving pages back and forth between physical memory and swap space. The amount of virtual address space that can be created is limited only by the amount of swap space. This section discusses some of the factors to consider when configuring swap space on your system. System Configuration and Tuning provides additional information about optimizing the use of swap space.

During a Full Installation, you can configure two swap areas: a primary swap partition named swap1 and an optional swap partition named swap2. Additional swap partitions can be configured after the installation is complete by using the procedures described in the System Administration guide.

During a Full Installation, you are asked to choose which disk partition to use for swap1. The default choice is partition b of the system disk.

Note

It is recommended that you create swap space equal to twice the size of physical memory.

To optimize the use of your swap space, spread out your swap space across multiple devices and use the fastest disks for swap devices. To ensure the best performance, place swap areas on different disks instead of placing multiple swap areas on the same disk. The amount of swap space you allocate also depends on the virtual memory requirements of the applications you plan to install.

Although you cannot choose swap strategy modes during the installation procedure, there are two strategies for swap allocation: immediate and over-commitment. By default, the swap strategy mode used for the operating systems is immediate mode, which means that swap space is allocated when modifiable virtual address space is created. This mode requires more swap space than over-commitment mode because it guarantees that there will be enough swap space if every modifiable virtual page is modified. Refer to the System Administration guide for more information about swap allocation strategies and how to switch from one swap allocation mode to the other after the installation.

Also keep in mind that by default, crash dumps temporarily are stored on the swap partition. This area is used to hold the crash dump until the system is rebooted and must be large enough to hold a single crash dump. This area is referred to as the crash dump partition. In the event of a system crash, the kernel writes the contents of physical memory to the swap partition. The amount of information written, and hence the size of the crash dump, depends on several factors:

The factor that determines the size of a partial crash dump is the amount of physical memory in use at the time of the crash by various kernel data structures that define the state of the system. The more tasks and threads that are active, the more kernel data structures that will be in use, and the larger the resulting partial crash dump.

Be prepared to add more swap space later if the system issues warning messages indicating that swap space is approaching exhaustion.