Asynchronous File I/O on Linux

[markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org (Mark Woodward)]

>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: <C8290D01-03C2-41D5-9199-1F36A18953DE-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
>Content-Type: text/plain; charset=us-ascii

>Again, this is not async I/O.  I'm not being pedantic.  I am trying to correct your gross misuse of the term "asynchronous".  >Multiple simultaneous reads do not require async I/O.  They require multiple threads.

Wait, even from a pedantic perspective, asynchronous I/O is the ability it issue disk I/O requests without blocking the process or thread. I am merely attempting to use this ability to optimize a particular type of operation on a file.

With tagged queuing on SATA and SCSI before it, a driver is able to issue multiple requests simultaneously to the device and the device is supposed to be able to get requested blocks in cache and return them over the device I/O bus.

>Anyway, I suspect that you are wasting your time with this.  Take a high performance database.  It goes fast because it >doesn't go to disk.  Reads from cache happen on the order of microseconds, three orders of magnitude faster than reads from >disk.  Shaving a few milliseconds off of read times from disk just makes a glacially slow process slightly less glacially >slow.

A few points: 
(1) The disk block I am requesting will never be in cache unless I have requested it.
(2) A "good database" i.e. not mySQL, something like Oracle, DB2, PostgreSQL, etc. do their own caching and manage their own data access. Oracle still has their own device level access system.
(3) A "few" (4) milliseconds shaved off a function that is run half a million to a million times is between 1/2 hour and an hour of wall clock time. That is important.
(4) If asynchronous I/O is not used, then I will *always" have the worst case scenario of purely sequential reads.

>You are also ignoring the effects of:
>* The effect of multiple spindles in RAID sets

Even with RAID I *still* get hit with a full I/O procedure from disk to process if the read is not issued asynchronously.

>* RAID cache such as you'll find on large storage frames

You are assuming a specific usage pattern that is not correct. I want to read N blocks from a file and thats it. No amount of caching will help because I'm not going to read or write more than once.

>* Solid-state drives which have no moving parts and thus negligible seek times.

This is absolutely true, but they are not popular enough to warrant ignoring spinning drives.

>* And probably a few other things that I don't recall off the top of my head.
>Any of which will probably make what you are trying to do go slower due to much different timings.

Are you really arguing, seriously, that 4 sequential reads operations (app->driver->disk-fetch-wait-disk->driver->app repeat) from a file couldn't possibly be improved upon if they were issued simultaneously to a SCSI or SATA disk, RAID system or even network file share? If that is what you are saying you are mistaken. From a hardware perspective, this is provably false. Look up tagged queuing on SATA disks.

http://en.wikipedia.org/wiki/Tagged_Command_Queuing

Now, that's *just* SATA and SCSI. On a RAID system operating on a SCSI or Fibre bus, the performance increase should be even better.