fsync with SETUP_IOPOLL and SETUP_SQPOLL

fsync with SETUP_IOPOLL and SETUP_SQPOLL

[Ashlie Martinez]

Hello,

I am playing around with some of the newer io_uring features on kernel
5.6-rc4 and I was curious why fsync always returns EINVAL when the
SETUP_IOPOLL flag is set when running on a file system (in my case xfs
since it supports iopoll). Is this because you expect all changes to
already be persisted on disk already? Do the assumptions change if for
this if one is using a file system rather than a raw block device (ex.
would I also need to use O_SYNC in addition to O_DIRECT at file-open
time)?

I am not super familiar with io_uring and how it interacts with file
systems vs. block devices, so any insights would be appreciated.

Thanks,
Ashlie Martinez

Re: fsync with SETUP_IOPOLL and SETUP_SQPOLL

[Jens Axboe]

On 3/9/20 7:31 PM, Ashlie Martinez wrote:
> Hello,
> 
> I am playing around with some of the newer io_uring features on kernel
> 5.6-rc4 and I was curious why fsync always returns EINVAL when the
> SETUP_IOPOLL flag is set when running on a file system (in my case xfs
> since it supports iopoll). Is this because you expect all changes to
> already be persisted on disk already? Do the assumptions change if for
> this if one is using a file system rather than a raw block device (ex.
> would I also need to use O_SYNC in addition to O_DIRECT at file-open
> time)?
> 
> I am not super familiar with io_uring and how it interacts with file
> systems vs. block devices, so any insights would be appreciated.

Polled IO cannot support any operation that needs to block for
completion, as the task submitting IO is also the one that needs to find
and reap completions. That's why you get -EINVAL when attempting to do
so.

You could potentially have a non-polled ring that you use for fsync in
combination with the polled ring. At least that would be one way to make
it work.

-- 
Jens Axboe