public inbox for [email protected]
 help / color / mirror / Atom feed
From: Andres Freund <[email protected]>
To: Jens Axboe <[email protected]>, [email protected]
Subject: What does IOSQE_IO_[HARD]LINK actually mean?
Date: Sat, 1 Feb 2020 01:18:39 -0800	[thread overview]
Message-ID: <[email protected]> (raw)

Hi,

Reading the manpage from liburing I read:
       IOSQE_IO_LINK
              When  this  flag is specified, it forms a link with the next SQE in the submission ring. That next SQE
              will not be started before this one completes.  This, in effect, forms a chain of SQEs, which  can  be
              arbitrarily  long. The tail of the chain is denoted by the first SQE that does not have this flag set.
              This flag has no effect on previous SQE submissions, nor does it impact SQEs that are outside  of  the
              chain  tail.  This  means  that multiple chains can be executing in parallel, or chains and individual
              SQEs. Only members inside the chain are serialized. Available since 5.3.

       IOSQE_IO_HARDLINK
              Like IOSQE_IO_LINK, but it doesn't sever regardless of the completion result.  Note that the link will
              still sever if we fail submitting the parent request, hard links are only resilient in the presence of
              completion results for requests that did submit correctly.  IOSQE_IO_HARDLINK  implies  IOSQE_IO_LINK.
              Available since 5.5.

I can make some sense out of that description of IOSQE_IO_LINK without
looking at kernel code. But I don't think it's possible to understand
what happens when an earlier chain member fails, and what denotes an
error.  IOSQE_IO_HARDLINK's description kind of implies that
IOSQE_IO_LINK will not start the next request if there was a failure,
but doesn't define failure either.

Looks like it's defined in a somewhat adhoc manner. For file read/write
subsequent requests are failed if they are a short read/write. But
e.g. for sendmsg that looks not to be the case.

Perhaps it'd make sense to reject use of IOSQE_IO_LINK outside ops where
it's meaningful?

Or maybe I'm just missing something.

Greetings,

Andres Freund

             reply	other threads:[~2020-02-01  9:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-01  9:18 Andres Freund [this message]
2020-02-01 11:30 ` What does IOSQE_IO_[HARD]LINK actually mean? Pavel Begunkov
2020-02-01 12:02   ` Andres Freund
2020-02-01 15:28     ` Pavel Begunkov
2020-02-01 18:06 ` Jens Axboe
2020-02-02  7:36   ` Andres Freund

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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