Re: lgwr/dbw0 did not issue pwrite64 sys call

From: Sidney Chen <>
Date: Sun, 27 Nov 2011 13:28:28 +0800
Message-ID: <>

It turn out it's because the ASMLIB is deployed on the server. AIO is enable by disk_asynch_io set to true as default. quote from note

*How To Check if Asynchronous I/O is Working On Linux [ID 237299.1]*
*ASM Inherently Performs Asynchronous I/O Regardless of
filesystemio_options Parameter [ID 751463.1]*

  • quote from 237299.1 === Caveat for ASMLibIf Oracle ASMLib (see ) is deployed, the *kiocb* structs are not used. ASMLib does not use the POSIX aio_*() functions. You will never see any *kioctx* or *kiocb* structures from ASMLib. It is far lower level than that.

In fact, ASMLib does AIO or SyncIO depending on how the I/O is passed to it, It makes no decisions at all. This is entirely up to kfk and the layers above it, kfk is entirely controlled by the disk_asynch_io parameter. So, we can check whether ASMLib is doing AIO by PL/SQL command "show param disk_asynch_io". (You can disable AIO by setting disk_asynch_io=false)

With ASMLib, AIO is done via ioctl() calls (2.4 kernel), or *read()* calls (2.6 kernel) on the ASM device. Whether ASMLib uses aio depends on whether oracle is configured to do aio, In oracle 10g, if ASMLib is in use, the i/o is asynchronous, because oracle 10g enables aio by default.

The strace when using ASMlib will show read calls that look like this:

*read(16, "MSA\0\2\0\10\0P\0\0\0\222\377\377\377_at_\313\373\5\0\0\0"..., 80) = 80*

The first 3 characters, byte-swapped, are ASM, indicating an ASMLib I/O command structure.

Sidney Chen

Received on Sat Nov 26 2011 - 23:28:28 CST

Original text of this message