When O_NONBLOCK write () is called, the write () call will take (that is, copy to the kernel buffer) everything, some or none of the data that you passed to it (if some bytes were received, write () the return value will indicate how many bytes it accepted ... if no one was accepted, write () will return -1, and errno will be set to EWOULDBLOCK). The number of bytes that write () takes will depend on how much free space in its kernel buffer is currently. After write () returns, you must remember how many of its bytes it has received, and then call select () (or poll () or some other mechanism) so that you are notified when there is more free space in the buffer places When there is more free space (i.e., at some time in the future), you can call write () again to send more bytes to the buffer.
aio_write (), on the other hand, will "take responsibility" for the data that you pass to the function, and report later when it has finished writing the data. With aio_write (), you don’t have to worry about the call accepting only part of your data buffer; he will either accept the whole thing or mistake. This will make your application I / O logic simpler in this regard; however, I think that asynchronous i / o has its own set of complicating factors, so it may not always be a victory. (I myself did not use aio _ * (), so I cannot give details)
As for why the write () function does not seem to take longer as the length of the recorded data increases ... that due to the fact that the non-blocking record () copies only (not one, not some or all) of the data which you pass to the buffer, and then immediately returns; it actually does not wait for the data to go to disk. Copying a (relatively small) sequence of bytes from your application buffer in the kernel buffer will always be fast, and the number of bytes copied will never be greater than the amount of empty space currently available in the kernel buffer, so even the number of bytes copied to the write () limited / few.