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:
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.
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.
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.
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.
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:
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.”
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”.
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.
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. |
Review “Planning an XFS Filesystem” to verify that you are ready to begin this procedure.
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.
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.
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=0If 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=0If 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=0Example 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=33680If 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=0If 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=0To 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.
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.
| 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.
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. |
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. |
Make a backup of the filesystem you are going to extend.
Unmount the /mnt filesystem:
# umount /mnt
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
Mount the /mnt filesystem:
# mount /dev/xlv/xlv0 /mnt
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 26399727Change 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.
| 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:
Load the miniroot.
Do a complete dump of filesystems on the system disk.
Repartition the system disk if necessary.
Create one or two new, empty XFS filesystems.
Restore the files from the filesystem dumps.
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. |
Review “Planning an XFS Filesystem” to verify that you are ready to begin this procedure.
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.
Use devnm to get the device name of the root disk partition, rootpartition. For example:
# devnm / /dev/dsk/dks0d1s0 /
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
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.
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.
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.
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.
Bring up the miniroot from system software CDs or a software distribution directory.
Switch to the shell prompt in inst:
Inst> sh
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
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.
Exit out of the shell:
# exit ... Inst>
If you do not need to repartition the system disk, skip to step 18.
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.
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
Load the miniroot again, using the same procedure you used in step 9.
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.Switch to the shell prompt in inst:
Inst> sh
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
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.
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
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
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
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
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.
| 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.
Review “Planning an XFS Filesystem” to verify that you are ready to begin this procedure.
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.
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.
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.
Unmount the partition:
# umount partition
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.
Mount the new filesystem with this command:
# mount partition mountdir
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.
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.
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:
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.
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.
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 megabytesThe 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.
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.
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.