Closed lihaohong6 closed 6 months ago
you should report it to the distro. That's quite an old kernel and this is fixed upstream. your code works fine on a newer kernel.
Thanks! I guess switching to Ubuntu might be the easier solution then.
Also, in an effort to replicate this issue on a different machine, I tried it on Ubuntu 22.04.3 LTS with kernel version 6.2. Strangely, io_uring_get_sqe
always returns NULL even with a properly initialized ring. If I follow the build instructions for liburing
, the programs in the examples
directory can be compiled with make
and ran properly, but when I try to compile io_uring-test.c
myself, the resulting binary is unable to read anything because, like other programs on that machine, io_uring_get_sqe
always returns NULL. The command used in compilation is
gcc -o a -g -O2 -Wall -D_GNU_SOURCE io_uring-test.c -luring
I'm sorry this is off-topic for this issue, but I could not figure out what's going on. Surely there's an obvious problem I overlooked.
Any chance you have an older version of liburing also installed on this system? try running with
LD_LIBRARY_PATH=
While setting LD_LIBRARY_PATH=
does not fix the problem, I installed liburing-dev
via the package manager and the program now works: both io_uring_get_sqe
and the file offset are functioning as expected on the Ubuntu machine. Thanks for your help!
I'm writing some data to disk and noticed that the file offset does not increase automatically after a write request is issued. If I issue two write requests through
liburing
, the second one will overwrite the first one since both are trying to write to the beginning of the file. The man page says settingoffset
to -1 will advance the file offset automatically, but that does not seem to be the case. Using these posix apis by themselves (write
andwritev
) do not cause any issues.A small example is below. The expected behavior is that 4096 bytes of numbers from 0 to 1023 are written to the file, followed by 4096 bytes of 0s. However, the file only contains 4096 bytes of 0s. If I remove the line
write_buffer_to_file(2)
, it now contains 4096 bytes of numbers, so it seems that the second call is overwriting the content of the first one. The fact thatlseek
always returns 0 confirms that the file offset never changes.The code snippet is compiled with g++ and ran on RHEL 9.3 with kernel 5.14. Maybe the old kernel version (and Red Hat tinkering with the kernel) is the culprit. I skimmed through older issues and asked on Stack Overflow without success, so perhaps this is a nontrivial issue?