From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: lobotomise xfs_trans_read_buf_map()
Date: Wed, 3 Dec 2014 09:45:18 +1100 [thread overview]
Message-ID: <20141202224518.GG18131@dastard> (raw)
In-Reply-To: <20141202165930.GA28571@infradead.org>
On Tue, Dec 02, 2014 at 08:59:30AM -0800, Christoph Hellwig wrote:
> On Tue, Dec 02, 2014 at 09:34:50AM +1100, Dave Chinner wrote:
> > The only way we can find a buffer that has not had IO completed on
> > it is if it had readahead issued on it, but we never do readahead on
> > buffers that we have already joined into a transaction. Hence this
> > condition cannot occur, and buffers locked and joined into a
> > transaction should always be marked done and not under IO.
>
> Should we add an ASSERT that would trigger when someone tries
> to issue readahead on a buffer with b_transp set?
Perhaps so.
> > bp = xfs_buf_read_map(target, map, nmaps, flags, ops);
> > - if (bp == NULL) {
> > - *bpp = NULL;
> > - return (flags & XBF_TRYLOCK) ?
> > - 0 : -ENOMEM;
> > + if (!bp) {
> > + if (!(flags & XBF_TRYLOCK))
> > + return -ENOMEM;
> > + return tp ? 0 : -EAGAIN;
>
> Can you fix the inconsistent return for the trylock case in a follow on
> patch? This difference doesn't look intentional to me, and I would
> be surprised if it's correctly handled in the callers.
Ok, I'll do an audit and make this common in a follow up patch. Just
to confirm:
if (!(flags & XBF_TRYLOCK))
return -ENOMEM;
return -EAGAIN;
is what you want to see, right?
> > }
> > +
> > if (bp->b_error) {
> > error = bp->b_error;
> > + if (!XFS_FORCED_SHUTDOWN(mp))
> > + xfs_buf_ioerror_alert(bp, __func__);
> > + bp->b_flags &= ~XBF_DONE;
> > xfs_buf_stale(bp);
> > - XFS_BUF_DONE(bp);
>
> The old non-tp case did a XFS_BUF_UNDONE, which you open code here,
> while the with-tp case did a XFS_BUF_DONE. I think this change needs
> a little explanation.
Consistency. A read failed on the buffer, so the contents are
undefined. XBF_DONE implies the contents of the buffer are valid
and so setting XBF_DONE is wrong. Further, the buffer is marked
stale, again indicating that the contents are invalid and that it
should never be written. This makes the XBF_DONE value redundant.
Hence it doesn't matter whether it is transaction context or not,
XBF_DONE should not be set on a stale buffer that failed a read....
I'll add a comment explaining this.
>
> > #ifdef DEBUG
> > - if (xfs_do_error && !(tp->t_flags & XFS_TRANS_DIRTY)) {
> > + if (xfs_do_error && (!tp || !(tp->t_flags & XFS_TRANS_DIRTY))) {
> > if (xfs_error_target == target) {
> > if (((xfs_req_num++) % xfs_error_mod) == 0) {
> > - xfs_force_shutdown(tp->t_mountp,
> > - SHUTDOWN_META_IO_ERROR);
> > xfs_buf_relse(bp);
> > - xfs_debug(mp, "Returning trans error!");
> > + xfs_debug(mp, "Returning error!");
> > return -EIO;
> > }
> > }
>
> I would suggest to kill this xfs_do_error error code, it's the last
> use of the never initialized xfs_do_error and xfs_error_target
> variables.
I was in two minds w.r.t. killing that code. My initial patch did
kill it, but I didn't in this rework. I'll update the patch to kill
it.
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-12-02 22:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-01 22:34 [PATCH] xfs: lobotomise xfs_trans_read_buf_map() Dave Chinner
2014-12-02 16:59 ` Christoph Hellwig
2014-12-02 22:45 ` Dave Chinner [this message]
2014-12-02 23:07 ` [PATCH v2] " Dave Chinner
2014-12-03 10:53 ` Christoph Hellwig
2014-12-03 10:51 ` [PATCH] " Christoph Hellwig
2014-12-03 14:09 ` Mark Tinguely
2014-12-03 19:54 ` Dave Chinner
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=20141202224518.GG18131@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--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