From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 8/9] xfs: introduce xfs_buf_submit[_wait]
Date: Sat, 16 Aug 2014 09:39:35 +1000 [thread overview]
Message-ID: <20140815233935.GY26465@dastard> (raw)
In-Reply-To: <20140815143558.GE4096@laptop.bfoster>
On Fri, Aug 15, 2014 at 10:35:58AM -0400, Brian Foster wrote:
> On Fri, Aug 15, 2014 at 04:39:06PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > There is a lot of cookie-cutter code that looks like:
> >
> > if (shutdown)
> > handle buffer error
> > xfs_buf_iorequest(bp)
> > error = xfs_buf_iowait(bp)
> > if (error)
> > handle buffer error
> >
> > spread through XFS. There's significant complexity now in
> > xfs_buf_iorequest() to specifically handle this sort of synchronous
> > IO pattern, but there's all sorts of nasty surprises in different
> > error handling code dependent on who owns the buffer references and
> > the locks.
> >
> > Pull this pattern into a single helper, where we can hide all the
> > synchronous IO warts and hence make the error handling for all the
> > callers much saner. This removes the need for a special extra
> > reference to protect IO completion processing, as we can now hold a
> > single reference across dispatch and waiting, simplifying the sync
> > IO smeantics and error handling.
> >
> > In doing this, also rename xfs_buf_iorequest to xfs_buf_submit and
> > make it explicitly handle on asynchronous IO. This forces all users
> > to be switched specifically to one interface or the other and
> > removes any ambiguity between how the interfaces are to be used. It
> > also means that xfs_buf_iowait() goes away.
> >
> > For the special case of delwri buffer submission and waiting, we
> > don't need to issue IO synchronously at all. The second pass to cal
> > xfs_buf_iowait() can now just block on xfs_buf_lock() - the buffer
> > will be unlocked when the async IO is complete. This formalises a
> > sane the method of waiting for async IO - take an extra reference,
> > submit the IO, call xfs_buf_lock() when you want to wait for IO
> > completion. i.e.:
> >
> > bp = xfs_buf_find();
> > xfs_buf_hold(bp);
> > bp->b_flags |= XBF_ASYNC;
> > xfs_buf_iosubmit(bp);
> > xfs_buf_lock(bp)
> > error = bp->b_error;
> > ....
> > xfs_buf_relse(bp);
> >
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > ---
>
> On a quick look at submit_wait this looks pretty good. It actually
> implements the general model I've been looking for for sync I/O. E.g.,
> send the I/O, wait on synchronization, then check for errors. In other
> words, a pure synchronous mechanism. The refactoring and new helpers and
> whatnot are additional bonus and abstract it nicely.
>
> I still have to take a closer look to review the actual code, but since
> we go and remove the additional sync I/O reference counting business,
> why do we even add that stuff early on? Can't we get from where the
> current code is to here in a more direct manner?
Simply because we need a fix that we can backport, and that fix is a
simple addition that does not significantly affect the rest of the
patchset...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-08-15 23:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 6:38 [RFC PATCH 0/9] xfs: clean up xfs_buf io interfaces Dave Chinner
2014-08-15 6:38 ` [PATCH 1/9] xfs: synchronous buffer IO needs a reference Dave Chinner
2014-08-15 13:18 ` Brian Foster
2014-08-15 23:17 ` Dave Chinner
2014-08-18 14:15 ` Brian Foster
2014-08-29 0:18 ` Christoph Hellwig
2014-08-15 6:39 ` [PATCH 2/9] xfs: xfs_buf_ioend and xfs_buf_iodone_work duplicate functionality Dave Chinner
2014-08-15 13:18 ` Brian Foster
2014-08-15 23:21 ` Dave Chinner
2014-08-18 14:15 ` Brian Foster
2014-08-29 0:22 ` Christoph Hellwig
2014-08-29 0:55 ` Dave Chinner
2014-08-15 6:39 ` [PATCH 3/9] xfs: rework xfs_buf_bio_endio error handling Dave Chinner
2014-08-15 13:18 ` Brian Foster
2014-08-15 23:25 ` Dave Chinner
2014-08-29 0:23 ` Christoph Hellwig
2014-08-15 6:39 ` [PATCH 4/9] xfs: kill xfs_bdstrat_cb Dave Chinner
2014-08-29 0:24 ` Christoph Hellwig
2014-08-15 6:39 ` [PATCH 5/9] xfs: xfs_bioerror can die Dave Chinner
2014-08-15 14:35 ` Brian Foster
2014-08-15 23:27 ` Dave Chinner
2014-08-29 0:28 ` Christoph Hellwig
2014-08-29 1:05 ` Dave Chinner
2014-08-15 6:39 ` [PATCH 6/9] xfs: kill xfs_bioerror_relse Dave Chinner
2014-08-29 0:32 ` Christoph Hellwig
2014-08-29 1:12 ` Dave Chinner
2014-08-29 18:26 ` Christoph Hellwig
2014-08-30 0:05 ` Dave Chinner
2014-08-15 6:39 ` [PATCH 7/9] xfs: clean up xfs_trans_buf_read_map Dave Chinner
2014-08-15 6:39 ` [PATCH 8/9] xfs: introduce xfs_buf_submit[_wait] Dave Chinner
2014-08-15 13:10 ` Christoph Hellwig
2014-08-15 23:37 ` Dave Chinner
2014-08-16 4:55 ` Christoph Hellwig
2014-08-15 14:35 ` Brian Foster
2014-08-15 23:39 ` Dave Chinner [this message]
2014-08-18 14:16 ` Brian Foster
2014-08-15 16:13 ` Brian Foster
2014-08-15 23:58 ` Dave Chinner
2014-08-18 14:26 ` Brian Foster
2014-08-15 6:39 ` [PATCH 9/9] xfs: check xfs_buf_read_uncached returns correctly Dave Chinner
2014-08-15 12:56 ` Christoph Hellwig
2014-08-15 23:58 ` Dave Chinner
2014-08-29 0:37 ` Christoph Hellwig
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=20140815233935.GY26465@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox