Chapter 6. Creating and Growing Filesystems
Prev |  | Next

## Chapter 6. Creating and Growing Filesystems

This chapter describes the procedures you must perform to create or grow (increase the size of) an XFS filesystem or to convert from an EFS filesystem to an XFS filesystem.

The major sections in this chapter are:

- “Planning an XFS Filesystem”

- “Making an XFS Filesystem”

- “Making a Filesystem From inst”

- “Making a Foreign Filesystem”

- “Growing an XFS Filesystem Onto Another Disk”

- “Converting Filesystems on the System Disk From EFS to XFS”

- “Converting a Filesystem on an Option Disk From EFS to XFS”

- “Checking for Adequate Free Disk Space When Converting to XFS Filesystems”

- “Dump and Restore Requirements When Converting to XFS Filesystems”

## Planning an XFS Filesystem

The following subsections discuss preparation for and choices you must make when creating an XFS filesystem. Each time you plan to make an XFS filesystem or convert a filesystem from EFS to XFS, review each section and make any necessary preparations.

### Prerequisite Software

If you are converting the root and `usr` filesystems to XFS, you must have software distribution CDs or access to a remote distribution directory for IRIX system software.

### Choosing the Filesystem Block Size and Extent Size

XFS allows you to choose the logical block size for each filesystem. (Physical disk blocks remain 512 bytes.) If you use a real-time subvolume on an XLV logical volume, you must also choose the extent size. The extent size is the amount of space that is allocated to a file each time it needs more space.

For XFS filesystems on disk partitions and logical volumes and for the data subvolume of filesystems on XLV volumes, the block size guidelines are as follows:

- The minimum block size is 512 bytes. Small block sizes increase allocation overhead which decreases filesystem performance, but in general, the recommended block size for filesystems under 100 MB and for filesystems with many small files is 512 bytes. The filesystem block size must be a power of two.

- The default block size is 4096 bytes (4K). This is the recommended block size for filesystems over 100 MB.

- The maximum block size is 65536 bytes (64K). Because large block sizes can waste space and lead to fragmentation, in general block sizes should not be larger than 4096 bytes (4K).

- For the root filesystem on systems with separate root and `usr` filesystems, the recommended block size is 512 bytes. For systems where root and `usr` are not separate filesystems, the recommended block size is 4096 bytes, the default block size.

- For news servers, it is recommended that you use a version 2 directory format with a filesystem block size of 512 bytes and a directory block size of 4096 bytes. For information on using version 2 directories see “Choosing the Filesystem Directory Format and Directory Block Size”.

Block sizes are specified in bytes in decimal (default), octal (prefixed by 0), or hexadecimal (prefixed by 0x or 0X). If the number has the suffix “k,” it is multiplied by 1024. If the number has the suffix “m,” it is multiplied by 1048576 (1024 * 1024).

The guidelines for the extent size are as follows:

- The extent size must be a multiple of the block size of the data subvolume.

- The minimum extent size is 4 KB.

- The maximum extent size is 1 GB.

- The default extent size is 64 KB.

- The extent size should be matched to the application and the stripe unit of the volume elements used in the real-time subvolume.

A filesystem extent is considered unwritten if it is allocated to a file and has never been written by anyone after the allocation. This can occur when you use `F_RESVSP` parameter of the `fcntl(2)` system call to preallocate space. If you preallocate space and then read the data when the extent is unwritten, you could see the old contents of the data. This could have been written by another user, and may break security.

When you define an XFS filesystem, you can specify whether unwritten extent tracking is on. This causes XFS to keep track of unwritten extents and does not allow a read to return old data. When unwritten extent tracking is on, a read on an unwritten extent returns a value of 0. Unwritten extent tracking is on by default in IRIX 6.5 systems and later.

### Choosing the Filesystem Directory Format and Directory Block Size

XFS supports two on-disk directory formats, referred to as version 1 and version 2 in `mkfs` output. The version you choose when you create a filesystem applies to all the directories in a filesystem. Version 1 is the original IRIX filesystem directory format; version 2 was added with the 6.5.5 release of IRIX and is the default.You choose the directory format with the `-n` parameter of the `mkfs` command.

An XFS file system with version 2 directory format allows you to select a logical block size for the filesystem directory that is greater than the logical block size of the filesystem. This allows you to choose a filesystem block size to match the distribution of data file sizes without adversely affecting directory operation performance. Using this option could improve performance for a filesystem with many small files, such as a news or mail filesystem. In this case, the filesystem logical block size could be small (512, 1K, or 2K bytes) and the logical block size for the filesystem directory could be large (4K or 8K bytes); this can improve the performance of directory lookups because the tree storing the index information has larger blocks and less depth.

You should consider setting a logical block size for a filesystem directory that is greater than the logical block size for the filesystem if you are supporting an application that reads directories (with the `readdir`(3C) or `getdents`(2) system calls) many times in relation to how much it creates and removes files. Using a small filesystem block size saves on disk space and on I/O throughput for the small files.

In an XFS file system with version 2 directory format, the data needed to perform a `readdir` operation is segregated from the index information. Directory data blocks can be “read-ahead” in a `readdir` on a version 2 directory block; this is not possible with a version 1 directory block. Performing read-ahead improves the `readdir` performance dramatically.

Because the data needed for a `readdir` operation and index information are separate in a version 2 directory block, the offset in a directory is limited to 32 bits. In a version 1 directory block, a 64-bit offset is used. A 64-bit offset can cause some interoperability problems for 32-bit clients such as NFS V2, DFS and 32-bit (O32) applications.

SGI recommends that all new XFS filesystems be created with version 2 directories. IRIX releases older than IRIX 6.5.5, however, are not be able to mount a filesystem created with a version 2 directory and will issue the following message when a mount is attempted:

    Wrong filesystem type: xfs

There is no means for converting a filesystem, in place, between version 1 and version directories. A filesystem can be converted between version 1 and version 2 directories by means of an `xfsdump`/`mkfs`/`xfsrestore` sequence.

For information on using the `-n` option of `mkfs` to select a version 1 directory format, see the `mkfs_xfs`(1M) man page.

### Choosing the Log Type and Size

Each XFS filesystem has a log that contains filesystem journaling records. This log requires dedicated disk space. This disk space doesn't show up in listings from the `df` command, nor can you access it with a filename.

The location of the disk space depends on the type of log you choose. The two types of logs are:

External |  | When an XFS filesystem is created on an XLV logical volume and log records are put into a log subvolume, the log is called an external log. The log subvolume is one or more disk partitions dedicated to the log exclusively.
Internal |  | When an XFS filesystem is created on a disk partition or XLV logical volume, or when it is created on an XLV logical volume that does not have a log subvolume, log records are put into a dedicated portion of the disk partition (or data subvolume) that contains user files. This type of log is called an internal log.

The guidelines for choosing the log type are as follows:

- If you want the log and the data subvolume to be on different partitions or to use different subvolume configurations for them, use an external log.

- If you want the log subvolume to be striped independently from the data subvolume (see “Volume Elements” in Chapter 3 for an explanation of striping), you must use an external log.

- If you are making the XFS filesystem on a disk partition (rather than on an XLV logical volume), you must use an internal log.

- If you are making the XFS filesystem on an XLV logical volume that has no log subvolume, you must use an internal log.

- If you are making the XFS filesystem on an XLV logical volume that has a log subvolume, you must use an external log.

For more information about XLV and log subvolumes, see Chapter 3, “XLV Logical Volume Concepts”.

The amount of disk space needed for the log is a function of how the filesystem is used. The amount of disk space required for log records is proportional to the transaction rate and the size of transactions on the filesystem, not the size of the filesystem. Larger block sizes result in larger transactions. Transactions from directory updates (for example, the `mkdir` and `rmdir` commands and the `create()` and `unlink()` system calls) cause more log data to be generated.

You can choose the amount of disk space to dedicate to the log (called the log size). The minimum log size for a filesystem is enforced by the size of the largest transaction, which depends on the filesystem and directory block sizes. The maximum log size is 64k blocks or 128 MB, whichever is smaller (this will depend on the block size).

For filesystems with a very high transaction activity, a large log size is recommended. You should avoid making your log too large, however, since a large log can increase filesystem mount time after a crash.

The default log size grows with the size of the filesystem up to the maximum log size, 128 megabytes, on a 1 terabyte filesystem.

For a filesystem which is contained in a XLV striped logical volume, the default internal log size is rounded up to a multiple of the stripe unit size. In this case, the user-specified size value must be a multiple of the stripe unit size.

For external logs, the size of the log is the same as the size of the log subvolume. The log subvolume is one or more disk partitions. You may find that you need to repartition a disk to create a properly sized log subvolume (see the section “Disk Repartitioning”).

For external logs, the size of the log is set when you create the log subvolume with the `xlv_make` command. For internal logs, the size of the log is specified with the `-l size=` option when you create the filesystem with the `mkfs` command.

The log size is specified in bytes as described in “Choosing the Filesystem Block Size and Extent Size”, or as a multiple of the filesystem block size by using the suffix “b.”

### Choosing Allocation Groups and Stripe Units

The data section of an XFS filesystem is divided into allocation groups. You can select the number of allocation groups when you create an XFS filesystem or, alternatively, you can select the size of an allocation group. The larger the number of allocation groups, the more parallelism can be achieved when allocating blocks and inodes. You should avoid selecting a very large number of allocation groups or an allocation group size that will yield a very large number of allocation groups; a large number of allocation groups causes an unreasonable amount of CPU time to be used when the filesystem is close to full.

The minimum allocation group size is 16MB; the maximum size is just under 4 GB.

The default number of allocation groups is 8, unless the filesystem is smaller than 128 MB or larger than 8 GB. When the filesystem is smaller than 128 MB, the default number of allocation groups is less than 8, since the minimum allocation group size is 16MB. In this case, the data section, by default, will be divided into as many allocation groups as possible that are at least 16MB. When the filesystem is larger than 8GB, but smaller than 64GB, the default number of allocation groups is greater than 8, with each allocation group approximately 1 GB in size. When the filesystem is larger than 64GB, the default number of allocation groups is still greater than 8, but the allocation group size is 4GB.

XFS allows you to select the stripe unit for a RAID device or XLV stripe volume. This ensures that data allocations, inode allocations, and the internal log will be aligned along stripe units when the end of file is extended and the file size is larger than 512KB. You specify stripe units in 512-byte block units or in bytes; when you specify stripe units in bytes, the value must be a multiple of the filesystem block size. See the `mkfs_xfs`(1M) man page for information on specifying stripe units.

When you specify a stripe unit, you also specify a stripe width. You specify a stripe width in 512-byte block units or in bytes. The stripe width must be a multiple of the stripe unit. The stripe width will be the preferred I/O size returned in the `stat()` system call. See the `mkfs_xfs`(1M) man page for information on specifying stripe width.

When used in conjunction with the `-b` option of the `mkfs` command, you can use the `-d su=` and `-d sw=` options to specify the stripe unit and stripe width in filesystem blocks.

For a RAID device, the default stripe unit is 0, indicating that the feature is disabled. It is prudent of the sysadmin to configure the stripe unit and width sizes of RAID devices. This should be done to avoid unexpected performance anomolies caused by the filesystem doing non-optimal I/O operations to the RAID unit. For example, if a block write is not aligned on a RAID stripe unit boundary and is not a full stripe unit, the RAID will be forced to do a read/modify/write cycle to write the data. This can have a significant performance impact. By setting the stripe unit size properly, XFS will avoid unaligned accesses.

For a striped XLV volume, the stripe unit that was specified when the XLV volume was created is provided by default. For information on what to consider when choosing a stripe unit size, see “Striped Volume Elements” in Chapter 3 in Chapter 3, “XLV Logical Volume Concepts”.

### Disk Repartitioning

Many system administrators may find that they want or need to repartition disks when they switch to XFS filesystems and/or XLV logical volumes. Some of the reasons to consider repartitioning are:

- If the system disk has separate partitions for root and `usr` filesystems, the root filesystem may be running out of space. Repartitioning is a way to increase the space in root (at the expense of the size of `usr`) or to solve the problem by combining root and `usr` into a single partition.

- System administration is a little easier on systems with combined root and `usr` filesystems.

- If you plan to use XLV logical volumes, you may want to put the XFS log into a small subvolume. This requires disk repartitioning to create a small partition for the log subvolume.

- If you plan to use XLV logical volumes, you may want to repartition to create disk partitions of equal size that can be striped or plexed.

Disk partitions are discussed in Chapter 1, “Disk Concepts”. Using `fx` to repartition disks is explained in “Repartitioning a Disk With fx” in Chapter 2.

## Making an XFS Filesystem

This section explains how to create an XFS filesystem on an empty disk partition or XLV logical volume. (For information about creating XLV logical volumes, see Chapter 4, “Creating and Administering XLV Logical Volumes”.)

| Tip: You can make an XFS filesystem on a disk partition or a logical volume using the graphical user interface of the `xfsm` command. For information, see its online help.

| Caution: When you create a filesystem, all files already on the disk partition or logical volume are destroyed.

1. Review “Planning an XFS Filesystem” to verify that you are ready to begin this procedure.

2. Identify the device name of the partition or logical volume where you plan to create the filesystem. This is the value of partition in the examples below. For example, if you plan to use partition 7 (the entire disk) of a SCSI option disk on controller 0 and drive address 2, partition is `/dev/dsk/dks0d2s7`. For more information on determining partition, see Table 1-4, “Introduction to XLV Logical Volumes” in Chapter 3, and the `dks`(7M) reference page.

3. If the disk partition is already mounted, unmount it:

       # umount partition

   Any data that is on the disk partition is destroyed. To convert the data rather than destroy it, use the procedure in “Converting a Filesystem on an Option Disk From EFS to XFS” instead.

4. If you are making a filesystem on a disk partition or on an XLV logical volume that does not have a log subvolume and want to use the default values for block size and log size, use this `mkfs` command to create the new XFS filesystem:

       # mkfs partition

   Example 6-1 shows the command line to create an XFS filesystem using the defaults and system output.

   Example 6-1. mkfs Command for an XFS Filesystem Using Defaults

       # mkfs /dev/dsk/dks0d4s7
       meta-data=/dev/dsk/dks0d4s7      isize=256    agcount=9, agsize=262144 blks
       data     =                       bsize=4096   blocks=2222178, imaxpct=25
                =                       sunit=0      swidth=0 blks, unwritten=1
       naming   =version 2              bsize=4096
       log      =internal log           bsize=4096   blocks=1200
       realtime =none                   extsz=65536  blocks=0, rtextents=0

5. If you are making a filesystem on a disk partition or on an XLV logical volume that does not have a log subvolume and want to specify the block size and log size, use this `mkfs` command to create the new XFS filesystem:

       # mkfs -b size=blocksize -l size=logsize partition

   blocksize is the filesystem block size (see “Choosing the Filesystem Block Size and Extent Size”) and logsize is the size of the area dedicated to log records (see “Choosing the Log Type and Size”). The default values are 4 KB blocks and a 1000-block log.

   Example 6-2 shows the command line used to create an XFS filesystem and the system output. The filesystem has a 10 MB internal log and a block size of 1 KB and is on the partition `/dev/dsk/dks0d4s7`.

   Example 6-2. mkfs Command for an XFS Filesystem With an Internal Log

       # mkfs -b size=1k -l size=10m /dev/dsk/dks0d4s7
       meta-data=/dev/dsk/dks0d4s7      isize=256    agcount=9, agsize=1048576 blks
       data     =                       bsize=1024   blocks=8888712, imaxpct=25
                =                       sunit=0      swidth=0 blks, unwritten=1
       naming   =version 2              bsize=4096
       log      =internal log           bsize=1024   blocks=10240
       realtime =none                   extsz=65536  blocks=0, rtextents=0

6. If you are making a filesystem on an XLV logical volume that has a log subvolume (for an external log), use this `mkfs` command to make the new XFS filesystem:

       # mkfs -b size=blocksize volume

   blocksize is the block size for filesystem (see “Choosing the Filesystem Block Size and Extent Size”), and volume is the device name for the volume.

   Example 6-3 shows the command line used to create an XFS filesystem on a logical volume `/dev/xlv/a` with a block size of 1K bytes and the system output.

   Example 6-3. mkfs Command for an XFS Filesystem With an External Log

       # mkfs -b size=1k /dev/xlv/a
       meta-data=/dev/xlv/a             isize=256    agcount=9, agsize=1048576 blks
       data     =                       bsize=1024   blocks=8888712, imaxpct=25
                =                       sunit=0      swidth=0 blks, unwritten=1
       naming   =version 2              bsize=4096
       log      =volume log             bsize=1024   blocks=32768
       realtime =none                   extsz=65536  blocks=0, rtextents=0

   Example 6-4 shows the command line used to create an XFS filesystem on a logical volume `/dev/xlv/xlv_data1` that includes a log, data, and real-time subvolumes and the system output. The default block size of 4096 bytes is used and the real-time extent size is set to 128 KB.

   Example 6-4. mkfs Command for an XFS Filesystem With a Real-Time Subvolume

       # mkfs -r extsize=128k /dev/xlv/xlv_data1
       meta-data=/dev/xlv/xlv_data1     isize=256    agcount=9, agsize=262144 blks
       data     =                       bsize=4096   blocks=2222178, imaxpct=25
                =                       sunit=0      swidth=0 blks, unwritten=1
       naming   =version 2              bsize=4096
       log      =volume log             bsize=4096   blocks=8192
       realtime =volume rt              extsz=131072 blocks=1077787, rtextents=33680

7. If you are making a filesystem with a version 2 directory format with a directory block size that is larger than the filesystem block size, use this `mkfs` command to create the new XFS filesystem:

       # mkfs -b size=blocksize -n size=dirblocksize partition

   blocksize is the filesystem block size (see “Choosing the Filesystem Block Size and Extent Size”) and dirblocksize is the directory block size (see “Choosing the Filesystem Directory Format and Directory Block Size”).

   Example 6-5 shows the command line used to create an XFS filesystem and the system output. The filesystem has a 512-byte filesystem block and a 4K directory block and is on the partition `/dev/dsk/dks0d4s7`. You might use this filesystem to store mail or news files.

   Example 6-5. mkfs Command for an XFS Filesystem Specifying Directory Block Size

       # mkfs -b size=512 -n size=4k /dev/dsk/dks0d4s7
       meta-data=/dev/dsk/dks0d4s7      isize=256    agcount=9, agsize=2097152 blks
       data     =                       bsize=512    blocks=17777424, imaxpct=25
                =                       sunit=0      swidth=0 blks, unwritten=1
       naming   =version 2              bsize=4096
       log      =internal log           bsize=512    blocks=4944
       realtime =none                   extsz=65536  blocks=0, rtextents=0

8. If you are making a filesystem that you will mount on a system running an IRIX release older than IRIX 6.5.5 and you need to create a filesystem with the older, version 1 directory format, use this `mkfs` command to create the new XFS filesystem:

       # mkfs -b -n version=1 partition

   Example 6-6 shows the command line used to create an XFS filesystem and the system output. The filesystem has a 512-byte filesystem block and a version 1 directory structure and is on the partition `/dev/dsk/dks0d4s7`.

   Example 6-6. mkfs Command for an XFS Filesystem with Version 1 Directory Format

       # mkfs -b size=512 -n version=1 /dev/dsk/dks0d4s7
       meta-data=/dev/dsk/dks0d4s7      isize=256    agcount=9, agsize=2097152 blks
       data     =                       bsize=512    blocks=17777424, imaxpct=25
                =                       sunit=0      swidth=0 blks, unwritten=1
       naming   =version 1              bsize=512
       log      =internal log           bsize=512    blocks=4944
       realtime =none                   extsz=65536  blocks=0, rtextents=0

9. To use the filesystem, you must mount it. For example:

       # mkdir mountdir
       # mount partition mountdir

   For more information about mounting filesystems, see “Manually Mounting Filesystems” in Chapter 7.

10. To configure the system so that the new filesystem is automatically mounted when the system is booted, add this line to the file `/etc/fstab`:

        partition mountdir xfs rw,raw=rawpartition 0 0

    where rawpartition is the raw version of partition. For example, if partition is `/dev/dsk/dks0d2s7`, rawpartition is `/dev/rdsk/dks0d2s7`.

    For more information about automatically mounting filesystems, see the section “Mounting Filesystems Automatically With the /etc/fstab File” in Chapter 7.

## Making a Filesystem From inst

| Caution: When you create a filesystem, all files already on the disk partition or logical volume are destroyed.

`mkfs` can be used from within the `inst` command to make filesystems. To make the root or `usr` filesystem on a system disk, you must use `inst` from the miniroot. There are two ways to use `mkfs`:

- The `mkfs` command on the Administrative Command Menu. The `mkfs` command makes an XFS filesystem and uses default values for the `mkfs` command options. With no argument, the `mkfs` command makes the root filesystem, and if a `usr` partition is present, a `usr` filesystem. Other filesystems can be made by giving a device file argument to `mkfs`.

- From a shell. Giving the `mkfs` command from a shell (give the command `sh`, not `shroot`) enables you to specify the `mkfs` command line, including options.

For more information about making filesystems from `inst`, see IRIX Admin: Software Installation and Licensing.

## Making a Foreign Filesystem

Under the IRIX operating system, you can use the `mkfp` command to create `hfs` (`mac`) and `dos` (`fat`) filesystems on devices such as floppies, floptical disks, SyQuest, Jaz, PC Cards, Zip, magneto-optical and hard drives.

The `mkfp` utility can create single `dos` partitions on floppies and floptical disks as well as multiple `dos` partitions on other forms of media. However, the `mkfp` utility can create only single `hfs` partitions spanning entire disks. You cannot use the `mkfp` utility to manipulate existing partitions on disk.

For information on using the `mkfp` utility, see the `mkfp`(1M) reference page. For further information on foreign filesystem types, see the `filesystems`(4) reference page. For information on checking and repairing foreign filesystems, see the `fpck`(1M) reference page.

| Note: If you have trouble creating a filesystem with `mkfp` on your system, you may need to use the filesystem creation utilities of the filesystem's native platform.

## Growing an XFS Filesystem Onto Another Disk

The procedure in this section explains how to grow an XFS filesystem onto another disk. When growing an XFS filesystem onto another disk, there are two possibilities:

- The XFS filesystem is on a disk partition.

- The XFS filesystem is on an XLV logical volume.

If the XFS filesystem is on an XLV logical volume, the additional disk can be added to the logical volume as an additional volume element. Instructions for doing this are in the section “Adding a Volume Element to a Plex (Growing an XLV Logical Volume)” in Chapter 4.

The following steps show how to grow a filesystem mounted at `/mnt` onto an XLV logical volume created out of the `/mnt` disk partition and a new disk. The procedure assumes that the new disk is installed on the system and partitioned.

| Caution: All files on the additional disk are destroyed by this procedure.

1. Make a backup of the filesystem you are going to extend.

2. Unmount the `/mnt` filesystem:

       # umount /mnt

3. Use `xlv_make` to create an XLV logical volume out of the `/mnt` partition and the new disk. The `/mnt` partition must be the first volume element in the data subvolume. For example:

       # xlv_make
       xlv_make> vol xlv0
       xlv0
       xlv_make> data
       xlv0.data
       xlv_make> plex
       xlv0.data.0
       xlv_make> ve dks0d4s7
       xlv0.data.0.0
       xlv_make> ve dks0d3s0
       xlv0.data.0.1
       xlv_make> end
       Object specification completed
       xlv_make> exit
       Newly created objects will be written to disk.
       Is this what you want?(yes)  yes
       Invoking xlv_assemble

4. Mount the `/mnt` filesystem:

       # mount /dev/xlv/xlv0 /mnt

5. Grow the XFS filesystem into the logical volume with the `xfs_growfs` command:

       # xfs_growfs /mnt
       meta-data=/mnt                   isize=256    agcount=9, agsize=2097152 blks
       data     =                       bsize=512    blocks=17777424, imaxpct=25
                =                       sunit=0      swidth=0 blks, unwritten=1
       naming   =version 2              bsize=4096
       log      =internal               bsize=512    blocks=4944
       realtime =none                   extsz=65536  blocks=0, rtextents=0
       data blocks changed from 17777424 to 26399727

6. Change the entry for `/mnt` in the file `/etc/fstab` to mount the logical volume rather than the disk partition:

       /dev/xlv/xlv0 /mnt xfs rw,raw=/dev/rxlv/xlv0 0 0

   Growing the filesystem is complete.

## Converting Filesystems on the System Disk From EFS to XFS

| Caution: The procedure in this section can result in the loss of data if it is not performed properly. It is recommended only for experienced IRIX system administrators.

This section explains the procedure for converting filesystems on the system disk from EFS to XFS. Some systems have two filesystems on the system disk, the root filesystem (mounted at `/`) and the `usr` filesystem (mounted at `/usr`). Other systems have a single, combined root and `usr` filesystem mounted at `/`. This procedure covers both cases but assumes that XLV logical volumes are not used on the system disk. The basic procedure for converting a system disk is as follows:

1. Load the miniroot.

2. Do a complete dump of filesystems on the system disk.

3. Repartition the system disk if necessary.

4. Create one or two new, empty XFS filesystems.

5. Restore the files from the filesystem dumps.

6. Reboot the system.

During this procedure, you can repartition the system disk if necessary. For example, you can convert from separate root and `usr` filesystems to a single, combined filesystem, or you can resize partitions to make the root partition larger and the `usr` partition smaller. See “Disk Repartitioning” for more information.

The early steps of this procedure ask you to identify the values of various variables, which are used later in the procedure. You may find it helpful to make a list of the variables and values for later reference. Be sure to perform only the steps that apply to your situation. Perform all steps as superuser.

| Caution: It is very important to follow this procedure as documented without giving additional `inst` or shell commands. Unfortunately, deviations from this procedure, even changing to a different directory or going from the `inst` shell to an `inst` menu when not directed to do so, can have very severe consequences from which recovery is difficult.

1. Review “Planning an XFS Filesystem” to verify that you are ready to begin this procedure.

2. Verify that your backups are up to date. Because this procedure temporarily removes all files from your system disk, it is important that you have a complete set of backups that have been prepared using your normal backup procedures. You will make a complete dump of the system disk starting at step 11, but you should have your usual backups in addition to the backup made during this procedure.

3. Use `devnm` to get the device name of the root disk partition, rootpartition. For example:

       # devnm /
       /dev/dsk/dks0d1s0 /

4. If the system disk has separate root and `usr` filesystems, use `devnm` to figure out the device name of the `usr` partition, usrpartition:

       # devnm /usr
       /dev/dsk/dks0d1s6 /usr

5. If you are using a tape drive as the backup device, use `hinv` to get the controller and unit numbers (tapecntlr and tapeunit) of the tape drive. For example:

       # hinv -c tape
       Tape drive: unit 2 on SCSI controller 0: DAT

   In this example, tapecntlr is 0 and tapeunit is 2.

6. If you are using a disk drive as your backup device, use `df` to get the device name (backupdevice) and mount point (backupfs) of the partition that contains the filesystem where you plan to put the backup. For example:

       # df
       Filesystem             Type  blocks     use   avail %use  Mounted on
       /dev/root               efs 1992630  538378 1454252  27%  /
       /dev/dsk/dks0d3s7       efs 3826812 1559740 2267072  41%  /disk3
       /dev/dsk/dks0d2s7       efs 2004550      23 2004527   0%  /disk2

   The filesystem mounted at `/disk2` has plenty of disk space for a backup of the system disk (/ uses 538,378 blocks, and `/disk2` has 2,004,527 blocks available). The backupdevice for `/disk2` is `/dev/dsk/dks0d2s7` and the backupfs is `/disk2`.

7. Create a temporary copy of `/etc/fstab` called `/etc/fstab.xfs` and edit it with your favorite editor. For example:

       # cp /etc/fstab /etc/fstab.xfs
       # vi /etc/fstab.xfs

   Make these changes in `/etc/fstab.xfs`:

   - Replace `efs` with `xfs` in the line for the root filesystem, /, if there is a line for the root filesystem.

   - If there is no line for the root filesystem, add this line:

         /dev/root   /   xfs rw,raw=/dev/rroot 0 0

   - If root and `usr` are separate filesystems and will remain so, replace `efs` with `xfs` in the line for the `usr` filesystem.

   - If root and `usr` have been separate filesystems, but the disk will be repartitioned during the conversion procedure so that they are combined, remove the line for the `usr` filesystem.

8. Shut down your workstation using the `shutdown` command or the System Shutdown item from the System Toolchest. Answer prompts as appropriate to get to the five-item System Maintenance Menu.

9. Bring up the miniroot from system software CDs or a software distribution directory.

10. Switch to the shell prompt in `inst`:

        Inst> sh

11. Create a full backup of the root filesystem by giving this command:

        # /root/sbin/dump 0uCf tapesize dumpdevice rootpartition

    tapesize is the tape capacity (also used for backup to disks) and dumpdevice is the appropriate device name for the tape drive or the name of the file that will contain the dump image. Table 6-1 gives the values of tapesize and dumpdevice for different tape drives and disk. tapecntlr and tapeunit in Table 6-1 are tapecntlr and tapeunit from step 5 in this section.

    Table 6-1. dump Arguments for Filesystem Backup

    Backup Device | tapesize | dumpdevice
    --- | --- | ---
    Disk | 2m | Use `/root/backupfs` ```/root.dump` for the root filesystem and `/root/backupfs` ```/usr.dump` for the `usr` filesystem
    DAT tape | 2m | `/dev/rmt/tpstapecntlr` ```dtapeunit` ```nsv`
    DLT tape | 10m | `/dev/rmt/tpstapecntlr` ```dtapeunit` ```nsv`
    EXABYTE 8mm model 8200 tape | 2m | `/dev/rmt/tpstapecntlr` ```dtapeunit` ```nsv`
    EXABYTE 8mm model 8500 tape | 4m | `/dev/rmt/tpstapecntlr` ```dtapeunit` ```nsv`
    QIC cartridge tape | 150k | `/dev/rmt/tpstapecntlr` ```dtapeunit` ```ns`

12. If `usr` is a separate filesystem, insert a new tape (if you are using tape), and create a full backup of the `usr` filesystem by giving this command:

        # /root/sbin/dump 0uCf tapesize dumpdevice usrpartition

    tapesize is the tape capacity (also used for backup to disks) and dumpdevice is the appropriate device name for the tape drive or the name of the file that will contain the dump image. Table 6-1 gives the values of tapesize and dumpdevice for different tape drives and disk.

13. Exit out of the shell:

        # exit
        ...
        Inst>

14. If you do not need to repartition the system disk, skip to step 18.

15. To repartition the system disk, use the standalone version of `fx`. This version of `fx` is invoked from the Command Monitor, so you must bring up the Command Monitor. To do this, quit out of `inst`, reboot the system, shut down the system, then request the Command Monitor. An example of this procedure is:

        Inst> quit
        ...
        Ready to restart the system.  Restart? { (y)es, (n)o, (sh)ell, (h)elp }: yes
        ...
        login: root
        # halt
        ...
        System Maintenance Menu
        ...
        Option? 5
        Command Monitor.  Type "exit" to return to the menu.
        >>

    On systems with a graphical System Maintenance Menu, choose the last option, Enter Command Monitor, instead of choosing option 5.

16. Boot `fx` and repartition the system disk so that it meets your needs. The following example shows how to use `fx` to switch from separate root and `usr` partitions to a single root partition.

        >> boot stand/fx
        84032+11488+3024+331696+26176d+4088+6240 entry: 0x89f97610
        114208+29264+19536+2817088+60880d+7192+11056 entry: 0x89cd31c0
        Currently in safe read-only mode.
        Do you require extended mode with all options available? (no) Enter
        SGI Version 6.4 ARCS   Sep 29, 1996
        fx: "device-name" = (dksc) Enter
        fx: ctlr# = (0) Enter
        fx: drive# = (1) Enter
        fx: lun# = (0) Enter
        ...opening dksc(0,1,0)
        ...drive selftest...OK
        Scsi drive type == SGI     SEAGATE ST31200N8640

        ----- please choose one (? for help, .. to quit this menu)-----
        [exi]t             [d]ebug/           [l]abel/           [a]uto
        [b]adblock/        [exe]rcise/        [r]epartition/     [f]ormat
        fx> repartition/rootdrive

        fx/repartition/rootdrive: type of data partition = (xfs) Enter
        Warning: you will need to re-install all software and restore user data
        from backups after changing the partition layout.  Changing partitions
        will cause all data on the drive to be lost.  Be sure you have the drive
        backed up if it contains any user data.  Continue? yes

        ----- please choose one (? for help, .. to quit this menu)-----
        [exi]t             [d]ebug/           [l]abel/           [a]uto
        [b]adblock/        [exe]rcise/        [r]epartition/     [f]ormat
        fx> exit

17. Load the miniroot again, using the same procedure you used in step 9.

18. Make an XFS filesystem for root:

        Inst> admin mkfs /dev/dsk/dks0d1s0
        Unmounting device “/dev/dsk/dks0d1s0” from directory “/root”.

        Make new file system on /dev/dsk/dks0d1s0 [yes/no/sh/help]: yes

        About to remake (mkfs) file system on: /dev/dsk/dks0d1s0
        This will destroy all data on disk partition: /dev/dsk/dks0d1s0.

                Are you sure? [y/n] (n): y

                Block size of filesystem 512 or 4096 bytes? 4096

        Doing: mkfs -b size=4096 /dev/dsk/dks0d1s0
        meta-data=/dev/rdsk/dks0d1s0     isize=256    agcount=8, agsize=31021 blks
        data     =                       bsize=4096   blocks=248165, imaxpact=25
                 =                       sunit=0      swidth=0 blks, unwritten=1
        naming   =version 1              bsize=4096
        log      =internal log           bsize=4096   blocks=1168
        realtime =none                   extsz=65536  blocks=0, rtextents=0
        Mounting file systems:

        NOTICE: Start mounting filesystem: /root
        NOTICE: Ending clean XFS mount for filesystem: /root
            /dev/miniroot            on  /
            /dev/dsk/dks0d1s0        on  /root

        Re-initializing installation history database
        Reading installation history .. 100% Done.
        Checking dependencies .. 100% Done.

19. Switch to the shell prompt in `inst`:

        Inst> sh

20. If you made the backup on disk, create a mount point for the filesystem that contains the backup and mount it:

        # mkdir /backupfs
        # mount backupdevice /backupfs

21. If you made the backup on tape, restore all files on the root filesystem from the backup you made in step 11 by putting the correct tape in the tape drive and giving these commands:

        # cd /root
        # mt -t /dev/rmt/tpstapecntlrdtapeunit rewind
        # restore rf dumpdevice

    You may need to be patient while the restore is taking place; it normally does not generate any output and it can take a while.

22. If you made the backup on disk, restore all files on the root filesystem from the backup you made in step 11 by giving these commands:

        # cd /root
        # restore rf /backupfs/root.dump

23. If you made a backup of the `usr` filesystem in step 12 on tape, restore all files in the backup by putting the correct tape in the tape drive and giving these commands:

        # cd /root/usr
        # mt -t /dev/rmt/tpstapecntlrdtapeunit rewind
        # restore rf dumpdevice

24. If you made a backup of the `usr` filesystem in step 12 on disk, restore all files in the backup by giving these commands:

        # cd /root/usr
        # restore rf /backupfs/usr.dump

25. Move the new version of `/etc/fstab` that you created in step 7 into place (the first command, which is optional, saves the old version of `/etc/fstab`):

        # mv /root/etc/fstab /root/etc/fstab.old
        # mv /root/etc/fstab.xfs /root/etc/fstab

26. Exit from the shell and `inst` and restart the system:

        # exit
        #
        Calculating sizes .. 100% Done.

        Inst> quit
        ...
        Ready to restart the system.  Restart? { (y)es, (n)o, (sh)ell, (h)elp }: yes
        Preparing to restart system ...

        The system is being restarted.

## Converting a Filesystem on an Option Disk From EFS to XFS

| Caution: The procedure in this section can result in the loss of data if it is not performed properly. It is recommended only for experienced IRIX system administrators.

This section explains how to convert an EFS filesystem on an option disk (a disk other than the system disk) to XFS. It assumes that XLV logical volumes are not used. You must be superuser to perform this procedure.

1. Review “Planning an XFS Filesystem” to verify that you are ready to begin this procedure.

2. Verify that your backups are up to date. Because this procedure temporarily removes all files from the filesystem you convert, it is important that you have a complete set of backups that have been prepared using your normal backup procedures. You will make a complete backup of the system disk in step 4, but you should have your usual backups in addition to the backup made during this procedure.

3. Identify the device name of the partition, which is the variable partition, where you plan to create the filesystem. For example, if you plan to use partition 7 (the entire disk) of an option disk on controller 0 and drive address 2, partition is `/dev/dsk/dks0d2s7`. For more information on determining partition (also known as a special file), see the `dks(7M)` reference page.

4. Back up all files on the disk partition to tape or disk because they will be destroyed by the conversion process. You can use any backup command (`Backup`, `bru`, `cpio`, `tar`, and so on) and back up to a local or remote tape drive or a local or remote disk. For example, the command for `dump` for local tape is:

       # dump 0uCf tapesize dumpdevice partition

   tapesize is the tape capacity (also used for backup to disks) and dumpdevice is the device name for the tape drive. Table 6-1 gives the values of tapesize and dumpdevice for different local tape drives and disk. You can get the values of tapecntlr and tapeunit used in the table from the output of the command `hinv –c tape`.

5. Unmount the partition:

       # umount partition

6. Use the `mkfs` command to create the new XFS filesystem:

       # mkfs -b size=blocksize -l size=logsize partition

   blocksize is the filesystem block size (see “Choosing the Filesystem Block Size and Extent Size”), and logsize is the size of the area dedicated to log records (see “Choosing the Log Type and Size”). Example 6-2 shows an example of this command line and its output.

7. Mount the new filesystem with this command:

       # mount partition mountdir

8. In the file `/etc/fstab`, in the entry for partition, replace efs with xfs. For example:

       partition mountdir xfs rw,raw=rawpartition 0 0

   rawpartition is the raw version of partition.

9. Restore the files to the filesystem from the backup you made in step 4. For example, if you gave the `dump` command in step 4, the commands to restore the files from tape are:

       # cd mountdir
       # mt -t device rewind
       # restore rf dumpdevice

   The value of device is the same as dumpdevice without `nsv` or other letters at the end.

You may need to be patient while the restore is taking place; it does not generate any output and it can take a while.

## Checking for Adequate Free Disk Space When Converting to XFS Filesystems

XFS filesystems may require more disk space than EFS filesystems for the same files. This extra disk space is required to accommodate the XFS log and as a result of block sizes larger than EFS's 512 bytes. However, XFS represents free space more compactly, on average, and the inodes are allocated dynamically by XFS, which can result in less disk space usage.

Use the following procedure to get a rough idea of how much free disk space will remain after a filesystem is converted to XFS:

1. Get the size in kilobytes of the filesystem to be converted and round the result to the next megabyte. For example:

       df -k
       Filesystem           Type  kbytes     use   avail %use  Mounted on
       /dev/root             efs  969857  663306  306551  68%  /

   This filesystem is 969857 KB, which rounds up to 970 MB.

2. If you plan to use an internal log (see “Choosing the Log Type and Size”), enter this command to get an estimate of the disk space required for the files in the filesystem after conversion:

       % xfs_estimate -i logsize -b blocksize mountpoint

   logsize is the size of the log. blocksize is the block size you chose for user files in “Choosing the Filesystem Block Size and Extent Size”. mountpoint is the directory that is the mount point for the filesystem. For example:

       % xfs_estimate -i 1m -b 4096 /
       / will take about 747 megabytes

   The output of this command tells you how much disk space the files in the filesystem (with a blocksize of 4096 bytes) and an internal log of size logsize will take after conversion to XFS.

3. If you plan to use an external log, give this command to get an estimate of the disk space required for the files in the filesystem after conversion:

       % xfs_estimate -e 0 -b blocksize mountpoint

   blocksize is the block size you chose for user files in the section “Choosing the Filesystem Block Size and Extent Size”. mountpoint is the directory that is the mount point for the filesystem. For example,

       % xfs_estimate -e 0 -b 4096 /
       / will take about 746 megabytes
               with the external log using 0 blocks or about 1 megabytes

   The first line of output from `xfs_estimate` tells you how much disk space the files in the filesystem will take after conversion to XFS. In addition to this, you need disk space on a different disk partition for the external log. Ignore the second line of output.

4. Compare the size of the filesystem from step 1 with the size of the files from step 2 or step 3. For example:

       970 MB - 747 MB = 223 MB free disk space
       747 MB / 970 MB = 77% full

   Use this information to decide if there will be an adequate amount of free disk space if this filesystem is converted to XFS.

If the amount of free disk space after conversion is not adequate, consider these option:

- Implement the usual solutions for inadequate disk space: remove unnecessary files, archive files to tape, move files to another filesystem, add another disk, and so on.

- Repartition the disk to increase size of the disk partition for the filesystem.

- If there is not sufficient disk space in the root filesystem and you have separate root and `usr` filesystems, switch to combined root and `usr` filesystems on a single disk partition.

- If the filesystem is on an XLV logical volume, increase the size of the volume.

- Create an XLV logical volume with a log subvolume elsewhere, so that all of the disk space can be allocated for user files.

## Dump and Restore Requirements When Converting to XFS Filesystems

The filesystem conversion procedures in “Converting Filesystems on the System Disk From EFS to XFS” and “Converting a Filesystem on an Option Disk From EFS to XFS” require that you dump the filesystems you plan to convert to tape or to another disk with sufficient free disk space to contain the dump image. Dumping to disk is substantially faster than dumping to tape.

When you convert a system disk, you must use the `dump` and `restore` commands. When you convert a filesystem on an option disk, you can use any backup and restore commands.

If you dump to a tape drive, follow these guidelines:

- Have sufficient tapes available for dumping the filesystems to be converted.

- If you are converting filesystems on a system disk, the tape drive must be local.

- If you are converting filesystems on option disks, the tape drive can be local or remote.

The requirements for dumping to a different filesystem are:

- The filesystem being converted must have 2 GB or less in use (the maximum size of the dump image file on an EFS filesystem) unless it is being dumped to an XFS filesystem.

- The filesystem that will contain the dump must have sufficient disk space available to hold the filesystems to be converted.

- If you are converting filesystems on a system disk, the filesystem where you place the dump must be local to the system.

- If you are converting filesystems on option disks, the filesystem you dump to can be local or remote.

Prev | Table of Contents | Next
Chapter 5. Filesystem Concepts |  | Chapter 7. Maintaining Filesystems