Async I/O [LWN.net]

Async I/O

Posted Apr 7, 2009 20:15 UTC (Tue) by lmb (subscriber, #39048)
In reply to: Async I/O by NAR
Parent article: Linux Storage and Filesystem workshop, day 1

Well, IO in the kernel is async anyway. This is about defining a usable user-space interface for it.

An event-driven FSA would benefit greatly from this; not everyone buys into multi-threaded paradigms. For some scenarios, this would make it possible to simplify the user-space implementation significantly.

to post comments

Async I/O

Posted Apr 20, 2009 9:59 UTC (Mon) by forthy (guest, #1525) [Link]

I don't understand why there was so much objection against the syslets - send the kernel a bunch of "IO instructions", and let it execute those asynchronously. Passing active messages (that's what it is) is a good idea, anyway; especially for networks like NFS4, where each "kernel call" is quite heavy. Syslets would scale a lot better (lower load, less context switches) than synchronous IO. Active message systems often had problems with programmers who did not understand them (like Display Postscript), so I guess this problem comes up again. It is not just a quality of implementation issue, it is a fundamental quality of understanding issue.

This overall doesn't sound good. With Ted T'so, it's even worse: He doesn't get it. It is not an option to a "save" filesystem which already takes a performance penalty by maintaining a journal, to corrupt data. It is an option to delay writing, and in effect, the 5 seconds update in ext3 is not what solved the problem, it is writing ordered. From an application writer point of view, this is a quality of implementation issue, but when I read the arguments, it's again an understanding problem. I'm concerned; maybe it is that those hard-core Linux hackers have been there for 20 years and are still sticking to 90s state-of-the-art?