On Tue, Aug 26, 2014 at 11:21:39AM +1000, Dave Chinner wrote: > From: Dave Chinner <dchinner@xxxxxxxxxx> > > It aborts recovery without freeing the current trans structure that > we are decoding. > What do you mean by "aborts recovery?" I don't see anything in the code that reflects that behavior. Do you mean it's an on-disk marker for completion? > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > --- > fs/xfs/xfs_log_recover.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c > index 1970732f..460cf98 100644 > --- a/fs/xfs/xfs_log_recover.c > +++ b/fs/xfs/xfs_log_recover.c > @@ -3587,8 +3587,9 @@ xlog_recovery_process_ophdr( > /* unexpected flag values */ > case XLOG_UNMOUNT_TRANS: > xfs_warn(log->l_mp, "%s: Unmount LR", __func__); > - error = 0; > - break; > + xlog_recover_free_trans(trans); > + return 0; > + The change to return here seems superfluous. It's fine, but just to check, were you intending to alter behavior in some way (e.g., return from xlog_recover_process_data())? Brian > case XLOG_START_TRANS: > xfs_warn(log->l_mp, "%s: bad transaction 0x%x", __func__, tid); > ASSERT(0); > -- > 2.0.0 > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
