Performance Management Guide

Reorganizing File Systems

You can reduce file system fragmentation as follows:

Copying the files to a backup media
Recreating the file system using the mkfs fsname command or deleting the contents of the file system
Reloading the files into the new file system

This procedure loads the file sequentially and reduces fragmentation.

Reorganizing a File System

For example, a system has a separate logical volume and file system hd11 (mount point: /home/op). Because we decide that file system hd11 needs to be reorganized, we perform the following steps:

Back up the file system by file name. If you back up the file system by i-node instead of by name, the restore command puts the files back in their original places, which would not solve the problem. Run the following commands:
```
# cd /home/op
# find . -print | backup -ivf/tmp/op.backup
```
This command creates a backup file (in a different file system), containing all of the files in the file system that is to be reorganized. If disk space on the system is limited, you can use tape to back up the file system.
Run the following commands:
```
# cd /
# unmount /home/op
```
If any processes are using /home/op or any of its subdirectories, you must terminate those processes before the unmount command can complete successfully.
Re-create the file system on the /home/op logical volume, as follows:
```
# mkfs /dev/hd11
```
You are prompted for confirmation before the old file system is destroyed. The name of the file system does not change.
To restore the original situation (except that /home/op is empty), run the following:
```
# mount /dev/hd11 /home/op
# cd /home/op
```
Restore the data, as follows:
```
# restore -xvf/tmp/op.backup >/dev/null
```
Standard output is redirected to /dev/null to avoid displaying the name of each of the files that were restored, which is time-consuming.
Review the large file inspected earlier (see Assessing File Placement with the fileplace Command), as follows
```
# fileplace -piv big1
```

We see that it is now (nearly) contiguous:

File: big1  Size: 3554273 bytes  Vol: /dev/hd11
Blk Size: 4096  Frag Size: 4096  Nfrags: 868   Compress: no
Inode: 8290  Mode: -rwxr-xr-x  Owner: hoetzel  Group: system
 
INDIRECT BLOCK: 60307
 
  Physical Addresses (mirror copy 1)                            Logical Fragment
 
  ----------------------------------                            ----------------
 
  0060299-0060306  hdisk1     8 frags    32768 Bytes,   0.9%    0008555-0008562
  0060308-0061167  hdisk1   860 frags  3522560 Bytes,  99.1%    0008564-0009423
 
  868 frags over space of 869 frags:  space efficiency = 99.9%
  2 fragments out of 868 possible:  sequentiality = 99.9%

The -i option that we added to the fileplace command indicates that the one-block gap between the first eight blocks of the file and the remainder contains the indirect block, which is required to supplement the i-node information when the length of the file exceeds eight blocks.

Some file systems or logical volumes should not be reorganized because the data is either transitory (for example, /tmp) or not in a file system format (log). The root file system is normally not very volatile and seldom needs reorganizing. It can only be done in install/maintenance mode. The same is true for /usr because many of these files are required for normal system operation.

Defragmenting a File System

If a journaled file system has been created with a fragment size smaller than 4 KB, it becomes necessary after a period of time to query the amount of scattered unusable fragments. If many small fragments are scattered, it is difficult to find available contiguous space.

To recover these small, scattered spaces, use the smitty dejfscommand or the defragfs command. Some free space must be available for the defragmentation procedure to be used. The file system must be mounted for read-write.