From: Avi Kivity <avi@scylladb.com>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-xfs@vger.kernel.org
Subject: Re: Detecting RWF_NOWAIT support
Date: Mon, 18 Dec 2017 09:38:42 +0200 [thread overview]
Message-ID: <f2fa5635-eafe-59d5-05c0-9f915cc5506b@scylladb.com> (raw)
In-Reply-To: <c4b15d8a-e868-5b31-f499-28151ba36116@suse.de>
On 12/18/2017 05:28 AM, Goldwyn Rodrigues wrote:
>
> On 12/16/2017 08:49 AM, Avi Kivity wrote:
>>
>> On 12/14/2017 09:15 PM, Goldwyn Rodrigues wrote:
>>> On 12/14/2017 11:38 AM, Avi Kivity wrote:
>>>> I'm looking to add support for RWF_NOWAIT within a linux-aio iocb.
>>>> Naturally, I need to detect at runtime whether the kernel support
>>>> RWF_NOWAIT or not.
>>>>
>>>>
>>>> The only method I could find was to issue an I/O with RWF_NOWAIT set,
>>>> and look for errors. This is somewhat less than perfect:
>>>>
>>>> - from the error, I can't tell whether RWF_NOWAIT was the problem, or
>>>> something else. If I enable a number of new features, I have to run
>>>> through all combinations to figure out which ones are supported and
>>>> which are not.
>>> Here is the return codes for RWF_NOWAIT
>>> EINVAL - not supported (older kernel)
>>> EOPNOTSUPP - not supported
>>> EAGAIN - supported but could not complete because I/O will be delayed
>> Which of these are returned from io_submit() and which are returned in
>> the iocb?
> These are returned in iocb.
Thanks.
>
>>> 0 - supported and I/O completed (success).
>>>
>>>> - RWF_NOWAIT support is per-filesystem, so I can't just remember
>>>> not to
>>>> enable RWF_NOWAIT globally, I have to track it per file.
>>> Yes, the support is per filesystem. So, the application must know if the
>>> filesystem supports it, possibly by performing a small I/O.
>> So the application must know about filesystem mount points, and be
>> prepared to create a file and try to write it (in case the filesystem is
>> empty) or alter its behavior during runtime depending on the errors it
>> sees.
> Well yes. Hopefully, the application knows what it is doing when it
> performs RWF_NOWAIT.
This type of interface makes it very hard to consume new kernel
facilities in a backward compatible way. The kernel should advertise
what support it provides; for example this support could be advertised
via statx(2).
For examples of facilities that advertise their capabilities, see
membarrier(2) and KVM.
prev parent reply other threads:[~2017-12-18 7:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-14 17:38 Avi Kivity
2017-12-14 19:15 ` Goldwyn Rodrigues
2017-12-16 14:49 ` Avi Kivity
2017-12-16 18:03 ` vcaputo
2017-12-16 18:12 ` vcaputo
2017-12-17 7:09 ` Avi Kivity
2017-12-18 3:28 ` Goldwyn Rodrigues
2017-12-18 7:38 ` Avi Kivity [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2fa5635-eafe-59d5-05c0-9f915cc5506b@scylladb.com \
--to=avi@scylladb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=rgoldwyn@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®