On Wed, Jun 03, 2020 at 11:02:07AM -0400, Brian Foster wrote:
> On Tue, Jun 02, 2020 at 07:42:34AM +1000, Dave Chinner wrote:
> > + if (xfs_buf_ioerror_sync(bp))
> > + goto out_stale;
> > +
> > + trace_xfs_buf_item_iodone_async(bp, _RET_IP_);
> > +
> > + cfg = xfs_error_get_cfg(mp, XFS_ERR_METADATA, bp->b_error);
> > + if (xfs_buf_ioerror_retry(bp, cfg)) {
> > + xfs_buf_ioerror(bp, 0);
> > + xfs_buf_submit(bp);
> > + return 1;
> > + }
> > +
> > + if (xfs_buf_ioerror_permanent(bp, cfg))
> > goto permanent_error;
> >
> > /*
> > * Still a transient error, run IO completion failure callbacks and let
> > * the higher layers retry the buffer.
> > */
> > - xfs_buf_do_callbacks_fail(bp);
> > xfs_buf_ioerror(bp, 0);
> > - xfs_buf_relse(bp);
> > - return true;
> > + return 2;
>
> ... that we now clear the buffer error code before running the failure
> callbacks. I know that nothing in the callbacks looks at it right now,
> but I think it's subtle and inelegant to split it off this way. Can we
> just move this entire block together into the type callbacks?
Sure. It's largely just deck chair rearragnement, though, because
the whole XFS_LI_FAILED ends up going away real soon. The next patchset
gets rid of it entirely for inode log items, and when the same
approach is applied to dquots, it no longer will be used by
anything and will be removed entirely.
IOWs, the future isn't "maybe error callbacks will do something
different", the future is "error callbacks don't exist any more".
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
