VERITAS File SystemÖ 3.5 (HP OnlineJFS/JFS3.5) AdministratorÆs Guide (December 2002)

Chapter 8

Quick I/O for Databases

Quick I/O Functionality and Performance

Many database administrators (DBAs) create databases on file systems because it makes common

administrative tasks (such as moving, copying, and backup) much simpler. However, putting databases on

file systems significantly reduces database performance. By using VERITAS Quick I/O, you can retain the

advantages of having databases on file systems without performance degradation.

Quick I/O uses a special naming convention to allow database applications to access regular files as raw

character devices. This provides higher database performance in the following ways:

• Supporting kernel asynchronous I/O

• Supporting direct I/O

• Avoiding kernel write locks

• Avoiding double buffering

Supporting Kernel Asynchronous I/O

Some operating systems provide kernel support for asynchronous I/O on raw devices, but not on regular files.

As a result, even if the database server is capable of using asynchronous I/O, it cannot issue asynchronous I/O

requests when the database is built on a file system. Lack of asynchronous I/O significantly degrades

performance. Quick I/O lets the database server take advantage of kernel supported asynchronous I/O

(through the asyncdsk or Posix AIO interface) on file system files accessed via the Quick I/O interface by

providing a character device node that is treated by the OS as a raw device.

Supporting Direct I/O

I/O on files using read() and write() system calls typically results in data being copied twice: once between

user and kernel space, and later between kernel space and disk. In contrast, I/O on raw devices is direct. That

is, data is copied directly between user space and disk, saving one level of copying. As with I/O on raw devices,

Quick I/O avoids the extra copying.

Avoiding Kernel Write Locks

When database I/O is performed via the write() system call, each system call acquires and releases a write

lock inside the kernel. This lock prevents simultaneous write operations on the same file. Because database

systems usually implement their own locks for managing concurrent access to files, write locks unnecessarily

serialize I/O operations. Quick I/O bypasses file system locking and lets the database server control data

access.

Avoiding Double Buffering

Most database servers implement their own buffer cache and do not need the system buffer cache. So the

memory used by the system buffer cache is wasted, and results in data being cached twice: first in the

database cache and then in the system buffer cache. By using direct I/O, Quick I/O does not waste memory on

double buffering. This frees up memory that can then be used by the database server buffer cache, leading to

increased performance.