From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 8/9] xfs: introduce xfs_buf_submit[_wait]
Date: Mon, 18 Aug 2014 10:16:09 -0400 [thread overview]
Message-ID: <20140818141608.GC30093@bfoster.bfoster> (raw)
In-Reply-To: <20140815233935.GY26465@dastard>
On Sat, Aug 16, 2014 at 09:39:35AM +1000, Dave Chinner wrote:
> 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...
>
Ok, it wasn't clear that multiple fixes was the intent. I guess it's
unforunate this won't see much tot testing, but we can find other ways
to make sure it's tested. ;)
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-08-18 14:16 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
2014-08-18 14:16 ` Brian Foster [this message]
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=20140818141608.GC30093@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.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