Asynchronous File I/O on Linux

[Mark Woodward]

OK, maybe we fell into a pedantic argument about what "asynchronous" 
means, but, what I wanted to do was issue some number of seek+read 
requests simultaneously on a single file from within a single context 
(thread or process) (to do this requires some form of asynchronous I/O) 
in order for those reads to be executed in parallel at the disk drive 
level so that tagged queuing in the SATA disk can be used to optimize 
the physical disk read order. As I explained before, a 7200 RPM disk has 
a rotational period of 8 or so milliseconds. (lets round to 10 for all 
the mechanical workings of the drive) *any* read from that disk will 
take, on average, 4~5 ms. So, 4 random reads of a file, issued 
sequentially will take around 20ms. If, however, you could issue those 
requests simultaneously (using asynchronous I/O) it is theoretically 
possible for those requests to get the the disk at close to the same 
time and a good SATA disk with a big enough internal buffer should be 
able to get those reads during the same 360~540 degree rotation of the 
disk platters. This could save about 5~10 ms per operation. So far, no 
one seems to know if it is even possible for Linux to take advantage of 
this and my tests seem to indicate that the standard APIs available do 
not. From: Richard Pieri <richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> Subject: Re: 
Asynchronous File I/O on Linux To: Boston Linux and Unix 
<discuss-mNDKBlG2WHs at public.gmane.org> Message-ID: 
<08234F47-926E-4447-817A-57FEEABB6B83-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> Content-Type: 
text/plain; charset=us-ascii On May 16, 2010, at 2:30 PM, Mark Woodward 
wrote:

> > 
> > While I can see your point, it would be impossible to do multiple simultaneous requests without some sort of asynchronous I/O capability.  The "random access" aspect of it comes out of using multiple file handles to a single file.
>   

Not true.  read() and friends usually block until the read completes or an error occurs.  If you open() a file with O_NONBLOCK then the read() call returns an error if there is nothing ready to be read.  This gets you nowhere near parallel reads, but it does get you a polling loop that chews up CPU while effectively blocking your program anyway.





> > Besides, you probably mean O_RDWR or O_RDONLY, O_WRONLY won't work in your example.
>   

Probably.  :) 

--Rich P.