From: Gleb Natapov <gleb@scylladb.com>
To: Brian Foster <bfoster@redhat.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: Question about non asynchronous aio calls.
Date: Thu, 8 Oct 2015 11:34:49 +0300 [thread overview]
Message-ID: <20151008083449.GF11716@scylladb.com> (raw)
In-Reply-To: <20151007150833.GB30191@bfoster.bfoster>
On Wed, Oct 07, 2015 at 11:08:34AM -0400, Brian Foster wrote:
> > > Second one is harder. We do need to write past the end of a file, actually
> > > most of our writes are like that, so it would have been great for XFS to
> > > handle this case asynchronously.
> >
> > You didn't say what kernel you're on, but these:
> >
> > 9862f62 xfs: allow appending aio writes
> > 7b7a866 direct-io: Implement generic deferred AIO completions
> >
> > hit kernel v3.15.
> >
> > However, we had a bug report about this, and Brian has sent a fix
> > which has not yet been merged, see:
> >
> > [PATCH 1/2] xfs: always drain dio before extending aio write submission
> >
> > on this list last week.
> >
> > With those 3 patches, things should just work for you I think.
> >
>
> These fix some problems in that code, but the "beyond EOF" submission is
> still synchronous in nature by virtue of cycling the IOLOCK and draining
> pending dio. This is required to check for EOF zeroing, and we can't do
> that safely without a stable i_size.
>
> Note that according to the commit Eric referenced above, ordering your
> I/O to always append (rather than start at some point beyond the current
> EOF) might be another option to avoid the synchronization here. Whether
> that is an option is specific to your application, of course.
>
Our IO should be always append IIRC, the above explains why most aio we
do is truly async, but may be somewhere there is a reordering and then
we see synchronous behaviour. Will have to check it.
--
Gleb.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2015-10-08 8:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 14:18 Question about non asynchronous aio calls Gleb Natapov
2015-10-07 14:24 ` Eric Sandeen
2015-10-07 15:08 ` Brian Foster
2015-10-07 15:13 ` Eric Sandeen
2015-10-07 18:13 ` Avi Kivity
2015-10-08 4:28 ` Dave Chinner
2015-10-08 5:21 ` Avi Kivity
2015-10-08 8:23 ` Gleb Natapov
2015-10-08 11:46 ` Dave Chinner
2015-10-12 12:37 ` Avi Kivity
2015-10-12 22:23 ` Dave Chinner
2015-10-13 9:11 ` Avi Kivity
2015-10-08 8:34 ` Gleb Natapov [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=20151008083449.GF11716@scylladb.com \
--to=gleb@scylladb.com \
--cc=bfoster@redhat.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.