On Thu, Feb 18, 2016 at 09:04:36AM +1100, Dave Chinner wrote:
> On Wed, Feb 17, 2016 at 08:40:08AM -0500, Brian Foster wrote:
> > On Wed, Feb 17, 2016 at 09:52:38AM +0100, Christoph Hellwig wrote:
> > > Merge xfs_trans_reserve and xfs_trans_alloc into a single function call
> > > that returns a transaction with all the required log and block
> > > reservations,
> > > and which allows passing transaction flags directly to avoid the
> > > cumbersome
> > > _xfs_trans_alloc interface.
> > >
> > > While we're at it we also get rid of the transaction type argument that
> > > has
> > > been superflous since we stopped supporting the non-CIL logging mode. The
> > > guts of it will be removed in another patch.
> > >
> > > Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> > > ---
> >
> > > @@ -165,7 +123,7 @@ xfs_trans_dup(
> > > * This does not do quota reservations. That typically is done by the
> > > * caller afterwards.
> > > */
> > > -int
> > > +static int
> > > xfs_trans_reserve(
> > > struct xfs_trans *tp,
> > > struct xfs_trans_res *resp,
> > > @@ -219,7 +177,7 @@ xfs_trans_reserve(
> > > resp->tr_logres,
> > > resp->tr_logcount,
> > > &tp->t_ticket, XFS_TRANSACTION,
> > > - permanent, tp->t_type);
> > > + permanent, 0);
> >
> > So this looks like it effectively breaks xlog_print_tic_res()..? I see
> > that is all removed in the subsequent patch, but the type still seems
> > like useful information in the event that an associated problem occurs
> > with the transaction. In fact, we just had a transaction overrun report
> > over the weekend (on irc) where at least I thought this was useful
> > (unfortunately it looks like I lost the reference to the syslog output).
>
> I've considered doing this removal myself in the past - doing
> somethign like embedding the return address of the
> xfs-trans_reserve() call in the ticket that is allocated tells us
> exactly where the call was made. This can be printed with %pS, and
> that gives us the function (and location in the function) the
> reservation was made. Hence we solve the problem of not
> knowing which call path triggered the problem.
>
> Hence I don't think we actually need to the type in every function
> call.
>
That sounds like a good idea to me.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
|