xfs
[Top] [All Lists]

Re: [PATCH V2] xfs: create helper for bmap finish & trans join in attr c

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH V2] xfs: create helper for bmap finish & trans join in attr code
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 13 Nov 2015 01:08:40 -0800
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20151112201231.GS19199@dastard>
References: <56441B8E.6070603@xxxxxxxxxx> <5644BEF8.6070201@xxxxxxxxxxx> <20151112165801.GA14854@xxxxxxxxxxxxx> <20151112201231.GS19199@dastard>
User-agent: Mutt/1.5.23 (2014-03-12)
On Fri, Nov 13, 2015 at 07:12:31AM +1100, Dave Chinner wrote:
> On Thu, Nov 12, 2015 at 08:58:01AM -0800, Christoph Hellwig wrote:
> > I think the problem here is simply that our interfaces suck.
> > xfs_trans_roll really needs to rejoin any inode to the new transaction
> > to that was joined to the previous one.  Once we've fixed that we can
> > get rid of the silly committed arguments and everyone will be happy.
> 
> xfs_trans_roll is not specifically for rolling transactions with
> locked inodes in them. We could use it for any object that needs
> multiple transactions to modify. e.g. we could roll transactions
> across an AGF (using hold+join) so that it remains locked across
> multiple allocation/free transactions.

xfs_trans_roll already logs the inode core, which requires the
inode to be attached to the transaction.  While I could see the
point of moving this out of the core __xfs_trans_roll into an
xfs_trans_roll_inode helper we might as well follow the current
interface for now.

<Prev in Thread] Current Thread [Next in Thread>