Asynchronous File I/O on Linux

[nmeyers-BigylZdZcsdmcu3hnIyYJQ at public.gmane.org (Nathan Meyers)]

On 05/16/2010 01:05 PM, Jerry Feldman wrote:
> 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
>> buffered calls (fread(3), fwrite(3), and all the other stdio stuff). But
>> you can destroy performance if you try this without really knowing what
>> you're doing.
>>
>>      
> 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.

Sorry... yes, I'm addressing a different level of buffering. Consider me 
ingloriously run down between first and second.

Nathan


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