Re: [PATCH 08/63] xfs: account for the refcount btree in the alloc/free log reservation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 28, 2016 at 12:20:05PM -0400, Brian Foster wrote:
> On Tue, Sep 27, 2016 at 07:54:20PM -0700, Darrick J. Wong wrote:
> > Every time we allocate or free an extent, we might need to split the
> > refcount btree.  Reserve some blocks in the transaction to handle
> > this possibility.
> > 
> 
> I'm probably not far along enough to grok how this all works, but I'm a
> bit confused by the requirement here. Why is generic block
> allocation/free a refcountbt matter? E.g., the function below is used
> for things like inode chunk allocation and whatnot, aren't those
> irrelevant to the refcountbt?

The original reason (pre-deferred ops) was that
xfs_allocfree_log_count() was used for calculating log reservations both
for user data and for metadata allocation activities, and we tried to
cram everything into one giant transaction.  As you point out, this can
lead to unnecessarily large transaction reservations.  Nowadays we
roll transactions with deferred ops and the refcount finish_one code
preemptively rolls the transaction if it thinks it might be close to the
overflow point.  I've been thinking we could just remove this since
refcount updates are their own transaction anyway.

Will try reverting and report back. :)

--D

> 
> Brian
> 
> > (Reproduced by generic/167 over NFS atop XFS)
> > 
> > Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> > [darrick.wong@xxxxxxxxxx: add commit message]
> > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> > ---
> >  fs/xfs/libxfs/xfs_trans_resv.c |    5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > 
> > diff --git a/fs/xfs/libxfs/xfs_trans_resv.c b/fs/xfs/libxfs/xfs_trans_resv.c
> > index 7c840e1..a59838f 100644
> > --- a/fs/xfs/libxfs/xfs_trans_resv.c
> > +++ b/fs/xfs/libxfs/xfs_trans_resv.c
> > @@ -67,7 +67,8 @@ xfs_calc_buf_res(
> >   * Per-extent log reservation for the btree changes involved in freeing or
> >   * allocating an extent.  In classic XFS there were two trees that will be
> >   * modified (bnobt + cntbt).  With rmap enabled, there are three trees
> > - * (rmapbt).  The number of blocks reserved is based on the formula:
> > + * (rmapbt).  With reflink, there are four trees (refcountbt).  The number of
> > + * blocks reserved is based on the formula:
> >   *
> >   * num trees * ((2 blocks/level * max depth) - 1)
> >   *
> > @@ -83,6 +84,8 @@ xfs_allocfree_log_count(
> >  	blocks = num_ops * 2 * (2 * mp->m_ag_maxlevels - 1);
> >  	if (xfs_sb_version_hasrmapbt(&mp->m_sb))
> >  		blocks += num_ops * (2 * mp->m_rmap_maxlevels - 1);
> > +	if (xfs_sb_version_hasreflink(&mp->m_sb))
> > +		blocks += num_ops * (2 * mp->m_refc_maxlevels - 1);
> >  
> >  	return blocks;
> >  }
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux