io_fsync(3)
β¨ io_fsync β bestie, let's get your file's whole in-core state synced up with the disk πΎβ¨
okay so this one is from Linux AIO, the io_fsync(3) page, and it's genuinely so useful once it clicks. buckle up π
πΈ NAME πΈ
io_fsync β Synchronize a file's complete in-core state with that on disk
π¦ SYNOPSIS π¦
#include <errno.h>
#include <libaio.h>
int io_fsync(io_context_t ctx, struct iocb *iocb, io_callback_t cb, int fd);
struct iocb {
void *data;
unsigned key;
short aio_lio_opcode;
short aio_reqprio;
int aio_fildes;
};
typedef void (*io_callback_t)(io_context_t ctx, struct iocb *iocb, long res, long res2);
like, look at that struct. it's giving β¨dataβ¨. anyway.
π DESCRIPTION π
so when you're doing asynchronous operations, sometimes you literally just need to get into a consistent state. and for AIO that means: you wanna know whether a certain request β or a whole group of requests β actually got processed. sure, you could just sit there waiting for the notification the system sends after the operation terminated, but bestieβ¦ that sometimes means wasting resources (mainly computation time π). not the vibe.
so here's the tea: calling this function forces all I/O operations queued at the time of the function call operating on the file descriptor iocb->io_fildes into the synchronized I/O completion state. periodt.
the io_fsync() function returns immediately, but the notification through the method described in io_callback will happen only after all requests for this file descriptor have terminated and the file is synchronized. π
and this part matters: requests for this very same file descriptor that are queued after the synchronization request are not affected. so don't come for them, they're innocent π
β RETURN VALUES β
Returns 0, otherwise returns errno.
π ERRORS π
EFAULTβiocbsreferenced data outside of the program's accessible address space. (rude of it, honestly)EINVALβctxrefers to an uninitialized aio context, theiocbpointed to byiocbscontains an improperly initializediocb,EBADFβ Theiocbcontains a file descriptor that does not exist.EINVALβ The file specified in theiocbdoes not support the given io operation.
yes bestie, EINVAL shows up twice up there, and I'm not about to gaslight you into thinking it doesn't. it's two different situations, both iconic, both annoying π
π«Ά SEE ALSO π«Ά
io(3), io_cancel(3), io_getevents(3), io_prep_pread(3), io_prep_pwrite(3), io_queue_init(3), io_queue_release(3), io_queue_run(3), io_queue_wait(3), io_set_callback(3), io_submit(3), errno(3).
and that's the whole page, bestie π this one's from Linux, dated 2019-07-23 β go sync something responsibly, mwah πβ¨πΈπ¦
π¦ where this page comes from
- alpine 3.22: libaio-doc 0.3.113-r2 Β· LGPL-2.1-or-later
- alpine 3.23: libaio-doc 0.3.113-r2 Β· LGPL-2.1-or-later
- alpine 3.24: libaio-doc 0.3.113-r2 Β· LGPL-2.1-or-later
- arch rolling: libaio 0.3.113-5 Β· LGPL-2.0-or-later
- debian bookworm: libaio-dev 0.3.113-4 Β· LGPL-2.1-or-later
- debian trixie: libaio-dev 0.3.113-8+b1 Β· LGPL-2.1-or-later
- ubuntu jammy: libaio-dev 0.3.112-13build1 Β· LGPL-2.1-or-later
- ubuntu noble: libaio-dev 0.3.113-6build1 Β· LGPL-2.1-or-later
- ubuntu noble: libaio-dev 0.3.113-6build1.1 Β· LGPL-2.1-or-later
- ubuntu questing: libaio-dev 0.3.113-8
- ubuntu resolute: libaio-dev 0.3.113-8build1 Β· LGPL-2.1-or-later
- ubuntu stonking: libaio-dev 0.3.113-9 Β· LGPL-2.1-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms