Asynchronous File I/O on Linux

[gaf-mNDKBlG2WHs at public.gmane.org (Jerry Feldman)]

On 05/16/2010 12:34 PM, Nathan Meyers wrote:
> If you know enough about your access patterns that you can do a better =

> job of buffering than what standard libc logic does, you can choose to =

> use the unbuffered I/O calls (read(2) and write(2)) instead of the=20
> buffered calls (fread(3), fwrite(3), and all the other stdio stuff). Bu=
t=20
> you can destroy performance if you try this without really knowing what=
=20
> you're doing.
>  =20
You are totally off base. This has nothing to do with the C language
standard I/O. The "unbuffered I/O calls (read(2) and write(2))" are NOT
unbuffered in Unix and Linux. The C standard library I/O creates
additional buffers in the process' context. But in terms of the system
calls, open(2), read(2), write(2), and ioctl(2) I/O is still fully
buffered using kernel buffers. The kernel buffers are controlled by the
various drivers.  The real advantage of the kernel buffers is that even
in random access I/O if you do a seek/read operation, if that data
happens to be in a buffer you get it. Same for a random write.
Certainly, I would agree if you know your access patterns you  certainly
have an advantage.  Remember that files are read and written in blocks.
If you know the disk geometry and the physical block sizes, as well as
the usage patters, you can do better.


--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846