Bug 167573 – AIO just doesn't work

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 167573 - AIO just doesn't work

Summary:	AIO just doesn't work

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	kernel (Show other bugs)
Sub Component:
Version:	4
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Jeff Moyer
QA Contact:	Brian Brock
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2005-09-05 15:27 EDT by Andy Ross
Modified:	2007-11-30 17:11 EST (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2005-09-12 16:21:51 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Example code (1.98 KB, text/plain) 2005-09-05 15:27 EDT, Andy Ross	no flags	Details
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Andy Ross 2005-09-05 15:27:09 EDT

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.

Comment 1 Andy Ross 2005-09-05 15:27:09 EDT

Created attachment 118478 [details]
Example code

Comment 2 Andy Ross 2005-09-05 16:28:10 EDT

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.

Comment 3 Jeff Moyer 2005-09-12 16:21:51 EDT

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.

Comment 4 Andy Ross 2005-09-12 17:45:50 EDT

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

Note You need to log in before you can comment on or make changes to this bug.