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
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]
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? :)