(K)aio only works when the target of the async I/O is a character
device-special file (raw disk I/O). There exists additional support
for host-based volume managers that e.g. create RAID volumes
(Sun Volume Manager, DiskSuite, Veritas). If these offer e.g.
raw entry points through /dev/vx/rdisk and /dev/md/rdisk
you should have kaio.
To decide if you really have kaio (in contrast to user land aio)
compile your test programm and then truss it:
$ truss -t kaio,lwp_crete aio /dev/rdsk/c0t3d0s0
In case of library aio, you see a bunch of lwp_create(..,..,..) and
kaio(..) failing with ERRVAL #22 (EINVAL). If you have made
it via kernel asynchronous IO you see kaio(...) succeeding.
(And by the way: Your performance should be better using kernel
aynchronous IO).
Michael Schulte
----- Original Message -----
From: "Matty" <[EMAIL PROTECTED]>
To: <perf-discuss@opensolaris.org>
Sent: Wednesday, August 10, 2005 9:49 PM
Subject: [perf-discuss] Kernel Asynchronous I/O
Howdy,
Does anyone know why kernel asynchronous I/O is limited to raw devices? Is
it possible to extend kaio to the file system layer? Would there be any
benefit? Is there a noticeable performance difference between the userland
and kernel asynchronous I/O implementation when UFS is used with large
Oracle OLTP workloads? Curious to see what folks have seen/measured.
Thanks for any insight,
- Ryan
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
