Différence entre POSIX AIO et libaio sous Linux ?

Question

Ce que je semblent pour comprendre :

POSIX AIO Les API sont prototypées dans <aio.h> et que vous liez votre programme avec librt(-lrt), alors que le programme libaio APIs dans <libaio.h> et votre programme est lié avec libaio (-laio).

Ce que je n'arrive pas à comprendre :

Le noyau traite-t-il différemment l'une ou l'autre de ces méthodes ?

2. est-ce que le O_DIRECT drapeau obligatoire pour utiliser l'un ou l'autre ?

Comme mentionné dans ce poste libaio fonctionne bien sans O_DIRECT lors de l'utilisation de libaio Ok, compris mais :

Selon R.Love Programmation du système Linux livre, Linux prend en charge aio (qui, je suppose, est POSIX AIO) sur des fichiers réguliers uniquement si elle est ouverte avec O_DIRECT Mais un petit programme que j'ai écrit (en utilisant aio.h, lié avec -lrt) qui appelle aio_write sur un fichier ouvert sans l'option O_DIRECT Le drapeau fonctionne sans problème.

Answer 1

Sous linux, les deux implémentations AIO sont fondamentalement différentes.

L'AIO POSIX est une implémentation au niveau de l'utilisateur qui effectue des E/S bloquantes normales dans plusieurs threads, donnant ainsi l'illusion que les E/S sont asynchrones. La principale raison de faire cela est que :

1. il fonctionne avec n'importe quel système de fichiers
2. il fonctionne (essentiellement) sur n'importe quel système d'exploitation (n'oubliez pas que la libc de gnu est portable)
3. il fonctionne sur les fichiers dont la mise en mémoire tampon est activée (c'est-à-dire sans drapeau O_DIRECT).

Le principal inconvénient est que la profondeur de votre file d'attente (c'est-à-dire le nombre d'opérations en suspens que vous pouvez avoir en pratique) est limitée par le nombre de threads que vous choisissez d'avoir, ce qui signifie également qu'une opération lente sur un disque peut bloquer une opération allant sur un autre disque. Cela affecte également les E/S (ou leur nombre) qui sont vues par le noyau et le planificateur de disque.

L'AIO du noyau (i.e. io_submit() et.al.) est le support du noyau pour les opérations d'E/S asynchrones, où les requêtes d'E/S sont en fait mises en file d'attente dans le noyau, triées par le planificateur de disque que vous avez, et probablement certaines d'entre elles sont transmises (dans un ordre optimal, on l'espère) au disque réel comme des opérations asynchrones (en utilisant TCQ ou NCQ). La principale restriction de cette approche est que tous les systèmes de fichiers ne fonctionnent pas aussi bien ou pas du tout avec des E/S asynchrones (et peuvent revenir à une sémantique de blocage), les fichiers doivent être ouverts avec O_DIRECT, ce qui entraîne un grand nombre d'autres restrictions sur les demandes d'E/S. Si vous n'ouvrez pas vos fichiers avec O_DIRECT, vous risquez d'avoir des problèmes de sécurité. Si vous n'ouvrez pas vos fichiers avec O_DIRECT, cela peut quand même "fonctionner", c'est-à-dire que vous recevez les bonnes données en retour, mais cela n'est probablement pas fait de manière asynchrone, mais revient à une sémantique de blocage.

Gardez également à l'esprit que io_submit() peut effectivement bloquer sur le disque dans certaines circonstances.