¿Diferencia entre POSIX AIO y libaio en Linux?

asynchronous linux-kernel

Question

Lo que parece entender:

POSIX AIO API POSIX AIO tienen prototipos en <aio.h> y usted vincula su programa con librt (-lrt), mientras que las API libaio en <libaio.h> y su programa está vinculado con libaio (-laio).

Lo que no puedo entender:

1. ¿El kernel maneja cualquiera de estos métodos de manera diferente?

2. ¿ O_DIRECT obligatoria la O_DIRECT para usar cualquiera de ellos?

Como se menciona en esta publicación , libaio funciona bien sin O_DIRECT al usar libaio Bien, entendido pero:

Según el libro de programación del sistema Linux de R.Love , Linux admite aio (que supongo que es POSIX AIO) en archivos normales solo si se abre con O_DIRECT Pero un pequeño programa que escribí (utilizando aio.h, vinculado con -lrt) que llama 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.

El POSIX AIO es una implementación de nivel de usuario que realiza una E / S de bloqueo normal en múltiples hilos, lo que da la ilusión de que las E / S son asíncronas. La razón principal para hacer esto es que:

1. funciona con cualquier sistema de archivos
2. funciona (esencialmente) en cualquier sistema operativo (tenga en cuenta que la libc de gnu es portátil)
3. funciona en archivos con almacenamiento en búfer habilitado (es decir, no se ha establecido el indicador O_DIRECT)

El principal inconveniente es que la 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 subprocesos que elija, lo que también significa que una operación lenta en un disco puede bloquear una operación que va 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 kernel 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 ellas son reenviadas ( 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 () realmente puede bloquear en el disco bajo ciertas circunstancias.