Oracle and fs_async

[Darren Murray]

Hi everyone,

I would like some advice on fs_async being turned on.

We have L2000's with FC60's and SC10's with fully redundancy. Is it really risky to turn fs_async to 1.

Cheers
Darren

[eran maor]

If fs_async is set to 1 it is enabled:
fs_async specifies whether or not asychronous writing of file
system data structures to disk is allowed. If no value for
fs_async is specified, synchronous writes are used.

If asynchronous writes are selected, HP-UX file system semantics
for NFS cluster environments are preserved. In addition, files
opened using open() with the 0_SYNC flag (synchronous writing)
will continue to be written synchronously when the asynchronous-writes
feature has been configured into the kernel.

Asynchronous writes to disk can improve file system performance
significantly. However, asynchronous writes can leave file system
data structures in an inconsistent state in the event of a system
crash.

Asynchronous writing as it relates to the fs_async kernel parameter
allows the system to update file system information on the disk in
a more convenient (hence faster) sequence rather than in a more
secure (safer but slower) sequence, thus reducing search and move
delays between writes. However, if a system crash occurs while these
operations are being performed, the risk of an inconsistent file system
that cannot be automatically repaired by fsck is significantly greater
than with synchronous writes.

If fs_async is set to allow asynchronous writes and a crash occurs,
fsck does not know what sequence was used, and thus will probably
require interactive assistance from the administrator while fixing
inconsistent file system information, repairing directory and inode
entries, etc.

Consequences of a Crash

If only synchronous writing is used, all updates to directories, file
inodes, free space lists, etc. are handled in a sequence that is known
to fsck. If a crash occurs while updating any disk block in the
sequence, fsck can readily determine where the crash occurred and
repair the missing update information, probably without assistance
from the system administrator.

If fs_async is set to allow asynchronous writes and a crash occurs,
fsck does not know what sequence was used, and thus will probably
require interactive assistance from the administrator while fixing
inconsistent file system information, repairing directory and inode

Why Allow Asynchronous Writes?

Waiting for synchronous writing and updating of disk blocks when
closing files after writing to them degrades the performance of
programs and applications that require frequent file and directory
write and close operations. Allowing asynchronous writing significantly
reduces those delays, producing a corresponding improvement in
performance. However, when applications are CPU intensive with
relatively little disk I/O, performance improvements are much lower.

When you should use Asynchronous Writes:

Asynchronous writing is advisable for improving system performance
if:

? Risk of power failure is low (very dependable power source
and/or uninterruptible power sources).

? Precautions have been taken to enhance data security
(sophisticated file system backup or redundancy strategies), or
potential loss of data due to a system crash is less important
than system performance.

? User applications require frequent opening, writing, and closing
of disk files and directories.

? Elimination of synchronous writing would improve system
performance sufficiently to offset any associated risks.

[James R. Ferguson · Accepted solution]

Hi Darren:

Eran's comments certainly cover the 'fs_async' parameter's pros and cons.

If you are running vxfs filesystems (as I would assume you are) then take a look at the Knowledge Base documents "Mount options explained" (#KBAN00000258) and "VXFS intent log explained" (#KBAN00000151). These offer good explanations of various JFS (vxfs) mount options, along with some suggestions for trading performance and integrity.

...JRF...