Diferencia entre POSIX AIO y libaio en Linux?

Question

Lo que parece de entender:

POSIX AIO API se prototipos en <aio.h> y que enlaza con su programa librtad (-lrt), mientras que los libaio API en <libaio.h> y su programa está vinculado con libaio (-laio).

Lo que no puedo averiguar:

1.Does el núcleo manejar la cualquiera de estos métodos de manera diferente?

2.¿Es obligatorio el marcado O_DIRECT para usar cualquiera de ellos?

Como se mencionó en this post, libaio funciona bien sin O_DIRECT cuando se utiliza libaio .Okay, pero entiende:

acuerdo con el sistema Linux de R.Love Programación libro, Linux soporta AIO (que supongo es POSIX AIO) en archivos regulares solo si está abierto con O_DIRECT. Pero un pequeño programa que escribí (usando aio.h, vinculado con -lrt) que llama a aio_write en un archivo abierto sin el indicador O_DIRECT funciona sin problemas.

Answer 1

En Linux, las dos implementaciones de AIO son fundamentalmente diferentes.

POSIX AIO es una implementación de nivel de usuario que realiza E/S de bloqueo normal en varios subprocesos, lo que da la ilusión de que las E/S son asincrónicas. La principal razón para hacer esto es que:

1. funciona con cualquier sistema de archivos
2. funciona (esencialmente) en cualquier sistema operativo (hay que tener en cuenta que la libc de GNU es portátil)
3. funciona en archivos con búfer activado (es decir, sin pabellón conjunto O_DIRECT)

el principal inconveniente es que su profundidad de la cola (es decir, el número de operaciones pendientes que puede tener en la práctica) está limitada por el número de hilos decide tener, que también significa que una operación lenta en un disco puede bloquear una operación a un disco diferente También afecta qué E/S (o cuántas) ven el kernel y el programador del disco también.

El kernel AIO (es decir, io_submit() et.al.) es soporte de núcleo para operaciones de E/S asíncronas, donde las solicitudes de io se ponen en cola en el kernel, ordenadas por el planificador de disco que tenga, presumiblemente algunas de se envían (en orden algo óptimo uno esperaría) al disco real como operaciones asíncronas (usando TCQ o NCQ). La principal restricción con este enfoque es que no todos los sistemas de archivos funcionan tan bien o en absoluto con asincronización de E/S (y pueden recaer en la semántica de bloqueo), los archivos deben abrirse con O_DIRECT, que viene con muchas otras restricciones en el Solicitudes de E/S. Si no puede abrir sus archivos con O_DIRECT, aún puede "funcionar", ya que puede recuperar los datos correctos, pero probablemente no se realice de forma asíncrona, sino que se vuelva a bloquear la semántica.

También tenga en cuenta que io_submit() puede bloquearse en el disco bajo ciertas circunstancias.