Asynchronous File I/O on Linux

[Nmeyers]

Linux already puts a fair amount of work into optimizing disk I/O scheduling
- I doubt you can affect performance by trying from user space to get
requests to hit at just the "right" time.

You may find this article interesting:

http://www.linuxjournal.com/article/6931

It discusses the various available I/O schedulers. If you find one that's a
better fit to your usage patterns, you can use the info here:

http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/

to change to using that scheduler.

Nathan


--------- Original Message --------
From: Mark Woodward <markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org>
To: Richard Pieri <richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
Cc: discuss-mNDKBlG2WHs at public.gmane.org
Subject: Re: Asynchronous File I/O on Linux
Date: 05/17/10 19:00

> 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.
> 
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
> 
>