Question about a kernel parameter : fs_async

[Herve BRANGIER]

Hi all,

I'm trying to tune my HPUX 11.00 systems. We
use these systems for softwares :

- about 250 binaries
- Ingres (6.4) Database (from CA)

I saw in one of these system that fs_async is
activate... and it seems to work faster than
other... But I don't know if this parameter can
be dangerous for the system integrity ?
Do you have some experience about this ?

TIA

Herv?

[Sridhar Bhaskarla]

fs_async parameter is to enable asynchronous writes to the disk subsystem. Check the following tutorial for more information. The drawback of having async writes is that in case of system crash, we may end up doing an fsck of the file system which may result a bit of loss of data.

http://docs.hp.com//hpux/onlinedocs/os/KCparam.FSasync.html

-Sri

[eran maor · Accepted solution]

Hi

i found a great doc that will explen to you if you should change this param .

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.

[harry d brown jr]

an important question is: what kind of disk storage are you using, and what levels of protection?

[Herve BRANGIER]

Hi

Thanks for your replies...

We use non-raid or mirror disks. These systems
can be on non secure powered environment...
Data are important (Database doesn't like write
errors).
So I prefer to use synchronous writing.

Thanks,

Herv?

[James R. Ferguson]

Hi Herve:

In lieu of enabling asynchronous I/O with the 'fs_async' kernel parameter, consider that Online JFS filesystems offer different mount options to balance integrity and performance.

Consider adding "mincache=direct,convosync=direct" to your database filesystem's mount options in /etc/fstab if you have Online JFS.

The documents "Mount options explained" (ID #KBAN00000258) and "VXFS intent log explained"
(ID #KBAN00000151) offfer good explanations of various JFS mount options, along with some suggestions for trading performance and integrity.

Regards!

...JRF...