[lustre-discuss] Asynchronous POSIX I/O with Lustre

[Sebastian Rettenberger]

Hi,

thanks for the feedback.

I found out a few things (especially for Linux) that might be interesting:

- glibc implements aio_read/aio_write in user-space using threads. Thus, 
they are always asynchronous but come with an overhead.

- The Linux kernel provides non-portable native asynchronous I/O through 
libaio (io_submit).

I tested native AIO function of Linux on Ext4, NFS, Lustre and GPFS. 
Only NFS performed the operation asynchronously and only with O_DIRECT. 
On all other file systems, the operation was turned in a synchronous 
operation.

Best regards,
Sebastian

On 05/12/2016 12:23 AM, Dilger, Andreas wrote:
> On 2016/05/10, 04:30, "Sebastian Rettenberger" <rettenbs at in.tum.de> wrote:
>
>> Hi,
>>
>> I am currently investigating in asynchronous I/O capability of different
>> file systems. I wounder whether Lustre supports aio_write and aio_read
>>from the POSIX standard.
>>
>> I found this bug report:
>> https://bugzilla.lustre.org/show_bug.cgi?id=11719
>> and this archived mail:
>> http://lists.lustre.org/htdig.cgi/lustre-discuss-lustre.org/2012-May/01108
>> 7.html
>>
>> Does anybody has any resent information on this? Is this docuemented in
>> the Lustre manual?
>
> The Lustre client does use the kernel ->aio_read() and ->aio_write()
> operations, but I don't know whether anyone has actually tested whether the
> IO operations will commit asynchronously or not.  If you have a test tool
> do verify this, it would definitely be interesting to know the results.
>
> Cheers, Andreas
>

-- 
Sebastian Rettenberger, M.Sc.
Technische Universität München
Department of Informatics
Chair of Scientific Computing
Boltzmannstrasse 3, 85748 Garching, Germany
http://www5.in.tum.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5183 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20160512/6cc1e800/attachment.bin>