FreeBSD Manual Pages
AIO(4) Kernel Interfaces Manual AIO(4) NAME aio -- asynchronous I/O DESCRIPTION The aio facility provides system calls for asynchronous I/O. Asynchronous I/O operations are not completed synchronously by the calling thread. In- stead, the calling thread invokes one system call to request an asynchro- nous I/O operation. The status of a completed request is retrieved later via a separate system call. Asynchronous I/O operations on some file descriptor types may block an AIO daemon indefinitely resulting in process and/or system hangs. Operations on these file descriptor types are considered "unsafe" and disabled by de- fault. They can be enabled by setting the vfs.aio.enable_unsafe sysctl node to a non-zero value. Asynchronous I/O operations on sockets, raw disk devices, and regular files on local filesystems do not block indefinitely and are always enabled. The aio facility uses kernel processes (also known as AIO daemons) to ser- vice most asynchronous I/O requests. These processes are grouped into pools containing a variable number of processes. Each pool will add or re- move processes to the pool based on load. Pools can be configured by sysctl nodes that define the minimum and maximum number of processes as well as the amount of time an idle process will wait before exiting. One pool of AIO daemons is used to service asynchronous I/O requests for sockets. These processes are named "soaiod<N>". The following sysctl nodes are used with this pool: kern.ipc.aio.num_procs The current number of processes in the pool. kern.ipc.aio.target_procs The minimum number of processes that should be present in the pool. kern.ipc.aio.max_procs The maximum number of processes permitted in the pool. kern.ipc.aio.lifetime The amount of time a process is permitted to idle in clock ticks. If a process is idle for this amount of time and there are more processes in the pool than the target minimum, the process will exit. A second pool of AIO daemons is used to service all other asynchronous I/O requests except for I/O requests to raw disks. These processes are named "aiod<N>". The following sysctl nodes are used with this pool: vfs.aio.num_aio_procs The current number of processes in the pool. vfs.aio.target_aio_procs The minimum number of processes that should be present in the pool. vfs.aio.max_aio_procs The maximum number of processes permitted in the pool. vfs.aio.aiod_lifetime The amount of time a process is permitted to idle in clock ticks. If a process is idle for this amount of time and there are more processes in the pool than the target minimum, the process will exit. Asynchronous I/O requests for raw disks are queued directly to the disk de- vice layer after temporarily wiring the user pages associated with the re- quest. These requests are not serviced by any of the AIO daemon pools. Several limits on the number of asynchronous I/O requests are imposed both system-wide and per-process. These limits are configured via the following sysctls: vfs.aio.max_buf_aio The maximum number of queued asynchronous I/O requests for raw disks permitted for a single process. Asynchronous I/O requests that have completed but whose status has not been retrieved via aio_return(2) or aio_waitcomplete(2) are not counted against this limit. vfs.aio.num_buf_aio The number of queued asynchronous I/O requests for raw disks sys- tem-wide. vfs.aio.max_aio_queue_per_proc The maximum number of asynchronous I/O requests for a single process serviced concurrently by the default AIO daemon pool. vfs.aio.max_aio_per_proc The maximum number of outstanding asynchronous I/O requests permit- ted for a single process. This includes requests that have not been serviced, requests currently being serviced, and requests that have completed but whose status has not been retrieved via aio_re- turn(2) or aio_waitcomplete(2). vfs.aio.num_queue_count The number of outstanding asynchronous I/O requests system-wide. vfs.aio.max_aio_queue The maximum number of outstanding asynchronous I/O requests permit- ted system-wide. Asynchronous I/O control buffers should be zeroed before initializing indi- vidual fields. This ensures all fields are initialized. All asynchronous I/O control buffers contain a sigevent structure in the aio_sigevent field which can be used to request notification when an opera- tion completes. For SIGEV_KEVENT notifications, the sigevent s sigev_notify_kqueue field should contain the descriptor of the kqueue that the event should be at- tached to, its sigev_notify_kevent_flags field may contain EV_ONESHOT, EV_CLEAR, and/or EV_DISPATCH, and its sigev_notify field should be set to SIGEV_KEVENT. The posted kevent will contain: Member Value ident asynchronous I/O control buffer pointer filter EVFILT_AIO flags EV_EOF udata value stored in aio_sigevent.sigev_value For SIGEV_SIGNO and SIGEV_THREAD_ID notifications, the information for the queued signal will include SI_ASYNCIO in the si_code field and the value stored in sigevent.sigev_value in the si_value field. For SIGEV_THREAD notifications, the value stored in aio_sigevent.sigev_value is passed to the aio_sigevent.sigev_notify_function as described in sigevent(3). SEE ALSO aio_cancel(2), aio_error(2), aio_read(2), aio_readv(2), aio_return(2), aio_suspend(2), aio_waitcomplete(2), aio_write(2), aio_writev(2), lio_lis- tio(2), sigevent(3), sysctl(8) HISTORY The aio facility appeared as a kernel option in FreeBSD 3.0. The aio ker- nel module appeared in FreeBSD 5.0. The aio facility was integrated into all kernels in FreeBSD 11.0. FreeBSD ports 15.quarterly January 2, 2021 AIO(4)
NAME | DESCRIPTION | SEE ALSO | HISTORY
Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=aio&sektion=4&manpath=FreeBSD+15.1-RELEASE+and+Ports.quarterly>