Re: Async I/O is NOT supppressed for filesystem datafiles in 8.1.5?

> I still think this is just a matter of wording. Suppose the parameters
> disk_asynch_io and _filesystemio_options are not tampered with and

_filesystemio_options is only valid in 8.1.7+. The versions in question are 8.1.5 and 8.1.6.

> Oracle and Solaris versions are fairly recent. Indeed the Sun or
> Oracle articles are inaccurate. The Sun paper should say "*kernelized*
> aio is suppressed for file system based files, not aio in general"

But if it was worded that way, then the footnote would have no significance  whatsoever. *Kernelized* AIO is suppressed (or, more accurately, not supported) on filesystems in ALL versions of Solaris, and thus has nothing to do with whether you're on Oracle 8.1.6 or Oracle 7.3.2. However, the distinction made was the Oracle release. So this is why they couldn't have meant to say, "Kernalized AIO is suppressed on filesystem datafiles in Oracle 8.1.5 and 8.1.6". That statement would suggest that kernelized AIO is supported on filesystems in versions of Oracle OTHER than 8.1.5-6, which is TOTALLY untrue since kernelized AIO is *only* for raw disk in Solaris.

> (unless you define aio as kaio and exclude the lwp-based aio emulation
> as non-aio; Really, do people call lwp-based aio emulation aio or not?

AIO encompasses both kernelized AND user-level libaio. Which gets used depends on the backend file. The user-land AIO, whereby a 'kaio' call is run to determine whether kernelized aio can be used or not -- then LWPs are spawned to simulate it, is Solaris's way of supporting filesystem AIO. It's been there in Solaris since 2.4. No matter, both are called AIO. To applications running on Solaris, the only exposed interface is the aio_write() and aio_read() library calls. This is what Oracle uses when disk_asynch_io is enabled. Under the hood, the library will execute the 'kaio()', lwp_*() calls, and 'pwrite64()' calls. Oracle has no idea about the latter calls going on in its behalf.

This is why it's ALL included in the AIO term umbrella.

> Isn't that the origin of all this debate?). The Oracle paper is still
> OK; Oracle doesn't know how aiowrite(3) is implemented by Solaris,
> whether by kaio(2) or libaio(3) emulation. But the Oracle paper
> shouldn't say a word about suppression or not, exactly because it
> passes the implementation to OS.

True. It's up the the OS to decide how AIO will be implemented. Solaris shields the application from that by just supplying the aio_write() library  call. The call itself takes care of which type of AIO happens under the covers.

However, Oracle states in Metalink that it won't even use aio_write(), the result of enabling 'disk_asynch_io', if DBWR detects that the datafiles  are on filesystems. Metalink states that it does this by running 'fstat()' on the open file descriptor of a datafile. This is why the docs from both Sun and Oracle state that *oracle* itself, on 8.1.5 and 8.1.6, will suppress AIO on filesystems -- not Solaris itself.

The issue is that I've found this to be untrue so far for 8.1.5.0. I have a ticket open on Metalink about it, and they've responded that the docs are TRUE, and that the subject is explained in an internal BugID doc. Needless to say, the ticket is still open until they can explain to me why my 8.1.5 instance is still making AIO calls to my filesystem datafiles. I'm attempting to determine if this is something  instituted on patch releases of Oracle 8.1.5 only (e.g., 8.1.5.1), and if this "feature" affects all Unix platforms, or just Solaris (since Sun is the only other vendor to mention this about 8.1.5-6).

> Does that answer your question?

As stated above, it does not. I hope that my statements above clarify the issue. If you read those docs at the URLs I sent you, you can clearly see how they all point to 8.1.5 and 8.1.6 doing something different  than 8.1.7 and <=8.1.4 when it comes to AIO use.

> Again, my own test on 8.1.7.2 on Solaris 2.6 shows that if
> disk_asynch_io is true, kaio() is attempted by DBWR with ENOTSUP
> returned, followed by lwp_cond_signal(), lwp_cond_wait() and
> pwrite64(). If disk_asynch_io is false, pwrite64() is not preceded by

This is what the Solaris libaio library does behind the scenes. It is all Solaris's doing. What *Oracle* does to start all this is an 'aio_write()' library call. 'Truss' is only showing you the lowerlevel  calls that result from it.

Besides, testing against an 8.1.7 instance is irrelevant. The only versions isolated as peculiar by Oracle and Sun are 8.1.5 and 8.1.6.

> kaio() and the lwp_cond_XX calls. I didn't see a fstat(2) call in
> truss. Maybe you used a slightly older version of Oracle or Solaris?

According to Oracle, the 'fstat()' call is done at DBWR startup. So you may not be able to see it after it has been running a while. My version of Oracle and Solaris are relevant versions, as the docs point to Oracle 8.1.5 on Solaris 2.6+ (which is what my environment uses).

> As Bob Sneed's message says, the logic is do kaio, if that fails, do
> lwp-based aio. Solaris does not use ioctl (you said fstat) to test
> whether it's raw prior to kaio, because that's too expensive. But the
> failed kaio call (if failed), is very lightweight, and so I infer that
> turning off aio (lwp-based) with disk_asynch_io in Oracle only sligtly
> helps.

Of course, if it made an 'fstat()' call before every write the performance  would be horrible. But, as I stated before, Metalink states that this call is only made on file open at startup, after which the decision is made from then on about async I/O or regular synch I/O.

Do you see where I'm coming from now? Oracle evidently made such a change in releases 8.1.5-8.1.6, as the Oracle rep replied that the docs I pointed to were indeed correct in that disk_asynch_io would be turned off by *oracle* itself. However, I'm simply fighting to get more clarification  on whether this suppression happens only in a patch release of 8.1.5 or not, since my 8.1.5.0 is clearly not suppressing it. Received on Mon Dec 31 2001 - 16:39:36 CST