JFS Tuning and Performance

File system reorganization attempts to collect large areas of free space by moving various file extents

and attempts to defragment individual files by copying the data in the small extents to larger extents.

The reorganization is not a compaction utility and does not try to move all the data to the front on the

file system.

Note

Fsadm extent reorganization may fail if there are not sufficient large free

areas to perform the reorganization. Fsadm -e should be used to

defragment file systems on a regular basis.

Transaction journaling

By definition, a journal file system logs file system changes to a “journal” in order to provide file

system integrity in the event of a system crash. VxFS logs structural changes to the file system in a

circular transaction log called the Intent Log. A transaction is a group of related changes that

represent a single operation. For example, adding a new file in a directory would require multiple

changes to the file system structures such as adding the directory entry, writing the inode information,

updating the inode bitmap, etc. Once the Intent Log has been updated with the pending transaction,

VxFS can begin committing the changes to disk. When all the disk changes have been made on disk,

a completion record is written to indicate that transaction is complete.

With the datainlog mount option, small synchronous writes are also logged in the Intent Log. The

datainlog mount option will be discussed in more detail later in this paper.

Since the Intent Log is a circular log, it is possible for it to “fill” up. This occurs when the oldest

transaction in the log has not been completed, and the space is needed for a new transaction. When

the Intent Log is full, the threads must wait for the oldest transaction to be flushed and the space

returned to the Intent Log. A full Intent Log occurs very infrequently, but may occur more often if many

threads are making structural changes or small synchronous writes (datainlog) to the file system

simultaneously.

Understanding your application

As you plan the various attributes of your file system, you must also know your application and how

your application will be accessing the data. Ask yourself the following questions:

 Will the application be doing mostly file reads, file writes, or both?

 Will files be accessed sequentially or randomly?

 What are the sizes of the file reads and writes?

 Does the application use many small files, or a few large files?

 How is the data organized on the volume or disk? Is the file system fragmented? Is the volume

striped?

 Are the files written or read by multiple processes or threads simultaneously?

 Which is more important, data integrity or performance?

How you tune your system and file systems depend on how you answer the above questions. No

single set of tunables exist that can be universally applied such that all workloads run at peak

performance.