AIO_FSYNC(2)

✨ AIO_FSYNC(2) ✨

okay bestie, gather round, because we're about to talk about asynchronous file synchronization in the System Calls Manual (that's section 2, the syscall girlies πŸ’…). this one's from the Debian build of the page, and it is lowkey iconic.


πŸ¦‹ NAME πŸ¦‹

aio_fsync β€” asynchronous file synchronization (REALTIME)

πŸŽ€ LIBRARY πŸŽ€

Standard C Library (libc, -lc) β€” yeah she lives in there, come find her πŸ’–

🌸 SYNOPSIS 🌸

#include <aio.h>

int
aio_fsync(int op, struct aiocb *iocb);

πŸ‘‘ DESCRIPTION πŸ‘‘

so the aio_fsync() system call lets the calling process yeet all the modified data tied to the descriptor iocb->aio_fildes over to a permanent storage device. and here's the thing β€” the call returns immediately after the synchronization request has been enqueued to the descriptor. the sync may or may not have finished by the time the call returns. no cap, it's giving "I sent the text, idk if they read it" energy 😭

the op argument can only be set to O_SYNC, which causes all currently queued I/O operations to be completed as if by a call to fsync(2). that's it. that's the whole vibe.

if _POSIX_PRIORITIZED_IO is defined, and the descriptor supports it, then the enqueued operation is submitted at a priority equal to that of the calling process minus iocb->aio_reqprio. main character priority math, periodt ✨

the iocb pointer may subsequently be used as an argument to aio_return() and aio_error() so you can figure out the return or error status for the enqueued operation while it's still in progress. use your tools bestie 🫢

if the request could not be enqueued (generally due to invalid arguments), the call returns without having enqueued the request. no request, no queue, no drama πŸ’€

the iocb->aio_sigevent structure can be used to request notification of the operation's completion as described in aio(4). so you can get a little ping when it's done, very demure 🌈

🚧 RESTRICTIONS 🚧

  • the Asynchronous I/O Control Block structure pointed to by iocb must remain valid until the operation has completed. do not let it ghost, fr fr.
  • the asynchronous I/O control buffer iocb should be zeroed before the aio_fsync() call to avoid passing bogus context information to the kernel. zero her out first, it's just polite πŸ’…
  • modification of the Asynchronous I/O Control Block structure is not allowed while the request is queued. hands off while she's working, okay? πŸ™ˆ
⚠️ these are not suggestions bestie, these are the rules. break them and the kernel will simply not be your friend.

πŸ’– RETURN VALUES πŸ’–

the aio_fsync() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error.

zero means slay. negative one means check errno. simple as πŸ“

πŸ”₯ ERRORS πŸ”₯

the aio_fsync() system call will fail if:

  • [EAGAIN] β€” the request was not queued because of system resource limitations. she's booked and busy, try again later 😭
  • [EINVAL] β€” the asynchronous notification method in iocb->aio_sigevent.sigev_notify is invalid or not supported.
  • [EOPNOTSUPP] β€” asynchronous file synchronization operations on the file descriptor iocb->aio_fildes are unsafe and unsafe asynchronous I/O operations are disabled.
  • [EINVAL] β€” a value of the op argument is not set to O_SYNC. (yes, EINVAL shows up twice, she's versatile ✨)

the following conditions may be synchronously detected when the aio_fsync() system call is made, or asynchronously, at any time thereafter. if they're detected at call time, aio_fsync() returns -1 and sets errno appropriately; otherwise the aio_return() system call must be called, and will return -1, and aio_error() must be called to determine the actual value that would have been returned in errno. two timelines, same lore ⏳

  • [EBADF] β€” the iocb->aio_fildes argument is not a valid descriptor.
  • [EINVAL] β€” this implementation does not support synchronized I/O for this file.

if the request is successfully enqueued, but subsequently cancelled or an error occurs, the value returned by the aio_return() system call is per the read(2) and write(2) system calls, and the value returned by the aio_error() system call is one of the error returns from the read(2) or write(2) system calls. so when in doubt, go read those two πŸ’œ

πŸ¦‹ SEE ALSO πŸ¦‹

aio_cancel(2), aio_error(2), aio_read(2), aio_return(2), aio_suspend(2), aio_waitcomplete(2), aio_write(2), fsync(2), sigevent(3), siginfo(3), aio(4)

the whole friend group honestly, go say hi 🌸

⭐ STANDARDS ⭐

the aio_fsync() system call is expected to conform to the IEEE Std 1003.1 ("POSIX.1") standard. certified, iykyk πŸ‘‘

🌈 HISTORY 🌈

the aio_fsync() system call first appeared in FreeBSD 7.0. a legend from day one πŸ’…


and that's the whole page, bestie 🫢 this one came from the Debian build, dated August 19, 2016, filed under AIO_FSYNC(2) β€” go forth and sync asynchronously, you absolute icon βœ¨πŸŽ€

πŸ“¦ where this page comes from