Re: [PATCH 08/71] xfs: introduce refcount btree definitions

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

 



On Tue, Sep 06, 2016 at 07:59:14AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 25, 2016 at 04:32:50PM -0700, Darrick J. Wong wrote:
> > Add new per-AG refcount btree definitions to the per-AG structures.
> > 
> > v2: Move the reflink inode flag out of the way of the DAX flag, and
> > add the new cowextsize flag.
> > 
> > v3: Don't allow pNFS to export reflinked files; this will be removed
> > some day when the Linux pNFS server supports it.
> > 
> > [hch: don't allow pNFS export of reflinked files]
> > [darrick: fix the feature test in hch's patch]
> 
> This was such a tiny check in the grand scheme of things, feel free to drop any mention of it

<nod>

> >  /*
> >   * For logging record fields.
> > @@ -105,6 +106,7 @@ do {    \
> >  	case XFS_BTNUM_INO: __XFS_BTREE_STATS_INC(__mp, ibt, stat); break; \
> >  	case XFS_BTNUM_FINO: __XFS_BTREE_STATS_INC(__mp, fibt, stat); break; \
> >  	case XFS_BTNUM_RMAP: __XFS_BTREE_STATS_INC(__mp, rmap, stat); break; \
> > +	case XFS_BTNUM_REFC: break; \
> 
> I'd merge the refcount stats into this patch, it's a fairly tiny
> addition to an already small patch.

I too thought it was a little strange to modify the same part of the
same macro in two successive patches, but was merely following the
pattern that Dave took in the initial rmap patches.  At the time I
naïvely thought that a larger number of patches with fewer changes
per patch would be less cognitive strain, but then the number of
reflink patches took off.

> > +static inline bool xfs_sb_version_hasreflink(struct xfs_sb *sbp)
> > +{
> > +	return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_5) &&
> 
> no need for the braces here..
> 
> >  {
> > -	mp->m_rmap_maxlevels = xfs_btree_compute_maxlevels(mp,
> > -			mp->m_rmap_mnr, mp->m_sb.sb_agblocks);
> > +	if (xfs_sb_version_hasreflink(&mp->m_sb))
> > +		mp->m_rmap_maxlevels = XFS_BTREE_MAXLEVELS;
> > +	else
> 
> Hmm, any good explanation for the magic XFS_BTREE_MAXLEVELS value
> here?  Maybe even one that could go into a comment?

On a non-reflink filesystem, the maximum number of rmap records is the
number of blocks in the AG, hence the max rmapbt height is
log_$maxrecs($agblocks).  However, with reflink each AG block can have
up to 2^32 (per the refcount record format) owners, which
means that theoretically we could face up to 2^64 rmap records.

Effectively that means that the max rmapbt height must be
XFS_BTREE_MAXLEVELS.  "Fortunately" we'll run out of AG blocks to feed
the rmapbt long before the rmapbt grows taller than that.  The reflink
code uses ag_resv_critical to disallow reflinking when less than 10%
of the per-AG metadata block reservation remains in the hope that the
caller will go beat up some other AG^W^W^W^W^Wmake a copy somewhere
else.

> > diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
> > index a3c2e2d..6141d68 100644
> > --- a/fs/xfs/xfs_mount.h
> > +++ b/fs/xfs/xfs_mount.h
> > @@ -393,6 +393,9 @@ typedef struct xfs_perag {
> >  	struct xfs_ag_resv	pag_meta_resv;
> >  	/* Blocks reserved for just AGFL-based metadata. */
> >  	struct xfs_ag_resv	pag_agfl_resv;
> > +
> > +	/* reference count */
> > +	__uint8_t	pagf_refcount_level;
> >  } xfs_perag_t;
> 
> The indentation doesn't seem to match the fields above.

Oops.

--D

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs




[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux