Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: directio and async io on redhat linux 3 and oracle 9i
To Noons:
I guess the create index on directio filesystem can be slower, is it
true?
To yong:
file handle 26200/26201 are datafiles on ufs. Others are on vxfs with
Qio. _filesystemio_options=directio.
truss dbwr result:
ioctl(26204, 0x0403, 0xFFFFFFFF7FFFCCDC) = 0 ioctl(13, 0x0403, 0xFFFFFFFF7FFFCB4C) = 0 ioctl(13, 0x0405, 0xFFFFFFFF7FFFCAC8) = 0 ioctl(26203, 0x0403, 0xFFFFFFFF7FFFCCDC) = 0 ioctl(13, 0x0403, 0xFFFFFFFF7FFFCB4C) = 0 ioctl(13, 0x0405, 0xFFFFFFFF7FFFCAC8) = 0 ioctl(26202, 0x0403, 0xFFFFFFFF7FFFCCDC) = 0 ioctl(26201, 0x0403, 0xFFFFFFFF7FFFCCDC) Err#25 ENOTTY ioctl(26201, _ION('f', 76, 0), 0x00000001) = 0 ----does this _ION means call with directio? ioctl(26200, 0x0403, 0xFFFFFFFF7FFFCCDC) Err#25 ENOTTY ioctl(26200, _ION('f', 76, 0), 0x00000001) = 0
[oracle_at_ebaysha2**8i]$pfiles 28606
28606: ora_dbw0_8i
26200: S_IFREG mode:0640 dev:272,21007 ino:7 uid:500 gid:500
size:10493952
O_RDWR|O_DSYNC|O_LARGEFILE FD_CLOEXEC /ufs/2.dbf
O_RDWR|O_DSYNC|O_LARGEFILE FD_CLOEXEC /ufs/1.dbf
And with your second test plan:
[oracle_at_ebaysha2**8i]$grep direct dio3.log
/1_at_1: -> libc:directio(0x6655, 0x1, 0xfffffffe7e355e40,
0x746571fefefefeff)
/1_at_1: <- libc:directio() = 0
/1_at_1: -> libc:directio(0x6654, 0x1, 0xfffffffe7e355e40,
0x746571fefefefeff)
/1_at_1: <- libc:directio() = 0
/1_at_1: -> libc:directio(0x6653, 0x1, 0xfffffffe7e3559e0,
0x746571fefefefeff)
/1_at_1: <- libc:directio() = 0
/1_at_1: -> libc:directio(0x6652, 0x1, 0xfffffffe7e3559e0,
0x746571fefefefeff)
/1_at_1: <- libc:directio() = 0
But for datafiles on vxfs, it is not supported in this way, that means _filesystemio_options=directio does not work for vxfs based datafiles.
Seems what you said is correct. Platform is solaris 10 for sparc.
Actually I am not quite familiar with the libc:directio :(. Do not have unix c programming experience.
THanks Received on Mon May 09 2005 - 05:11:50 CDT