The AIO interfaces in the current FC4 kernel don't seem to work at all. See the attached file, which is linked against libaio and can be built with: gcc -o laio laio.c -laio Pass it a file name, and it will attempt to read the file using the AIO syscalls. The AIO event completes, and strace shows that the proper syscalls were made, but the "res" field is invariably set to -EINVAL. No I/O occurs, as you can see by examining the request buffer in gdb. The problem appears to be in the kernel, not libaio. I have another, rather hacked up (the AIO syscalls and definitions don't appear in any FC4 headers, so I had to hard-code them) program that uses the raw system calls and shows exactly the same behavior. I have confirmed behavior in both i386 and x86_64 mode using kernel 2.6.12-1.1447_FC4 and with a custom build 2.6.13 kernel. I also built the libaio 0.3.104 source distribution and ran its test suite in the "harness" directory. I saw a *lot* of failures, although I didn't investigate carefully and am no expert on libaio.
Created attachment 118478 [details] Example code
OK, I think I figured this out. Not only does the request buffer need to be aligned by 512 bytes to match the device block size, the nbytes field of the read request must also be an integer multiple of 512. That's, strange and counter to the libaio man pages* which state that the nbytes field is simply the size of the buffer. * Which are missing from the libaio-devel RPM, as detailed in a separate bug I discovered this morning.
Yes, there are strict alignment restrictions when using O_DIRECT, which is currently required by AIO in FC. The alignment is page sized granularity, however, not disk block sized.
That's fine for now. I'm happy with the current situation. Immediate suggestions: + Add libaio man pages to the RPM. + Fix documentation to reflect O_DIRECT and alignment requirements, only some of which I was able to intuit by reading sample code. Note that there are lots of sources (including the libaio sample code) which mention a 512 byte alignment requirement. I never bothered to check what the returned values were, so they might have been hitting page boundaries anyway. Obviously RH can't fix all of that, but pushing sane/small changes to the man pages upstream should be doable, hopefully? :)