Разница между POSIX AIO и libaio в Linux?

Что я понимаю:

POSIX AIO API создаются прототипом в <aio.h>, и вы связываете свою программу с librt (-lrt), а API libaio в <libaio.h> и ваша программа связана с libaio (-laio).

Что я не могу понять:

1. Разве ядро обрабатывает один из этих методов по-разному?

2.Если флаг O_DIRECT обязателен для использования любого из них?

Как упоминалось в этом сообщении, libaio отлично работает без O_DIRECT при использовании libaio.Okay, понял, но:

Согласно книге программирования Linux LLove Linux, Linux поддерживает aio (который я предполагаю, это POSIX AIO) на обычных файлах, только если он открыт с помощью O_DIRECT. Но небольшая программа, которую я написал (используя aio.h, связанную с -lrt), который вызывает aio_write в файле, открытом без флага O_DIRECT, без проблем.

Ответ 1

В linux две реализации AIO принципиально разные.

POSIX AIO представляет собой реализацию на уровне пользователя, которая выполняет обычные блокирующие операции ввода-вывода в нескольких потоках, что создает иллюзию того, что операции ввода/вывода являются асинхронными. Основная причина заключается в следующем:

он работает с любой файловой системой
он работает (по существу) на любой операционной системе (имейте в виду, что gnu libc переносится)
он работает с файлами с включенной буферизацией (т.е. не установлен флаг O_DIRECT)

Основной недостаток заключается в том, что ваша глубина очереди (то есть количество выдающихся операций, которые вы можете иметь на практике) ограничена количеством потоков, которые вы выбрали, что также означает, что медленная операция на одном диске может блокировать операцию переход на другой диск. Это также влияет на то, какие операции ввода-вывода (или сколько) просматриваются ядром и планировщиком дисков.

Ядро AIO (т.е. io_submit() et.al.) является поддержкой ядра для асинхронных операций ввода-вывода, где запросы io фактически находятся в очереди в ядре, отсортированные по любому планировщику диска, по-видимому, некоторые из них (в некотором оптимальном порядке можно надеяться) на фактический диск в виде асинхронных операций (с использованием TCQ или NCQ). Основное ограничение этого подхода заключается в том, что не все файловые системы работают так хорошо или вообще с асинхронным вводом-выводом (и могут вернуться к блокирующей семантике), файлы должны быть открыты с помощью O_DIRECT, который содержит множество других ограничений на Запросы ввода-вывода. Если вы не можете открыть свои файлы с помощью O_DIRECT, он все равно может "работать", так как вы получаете правильные данные назад, но это, вероятно, не выполняется асинхронно, а возвращается к блокирующей семантике.

Также имейте в виду, что io_submit() может фактически блокироваться на диске при определенных обстоятельствах.