Re: [PATCH 5/7] xfs: implement block reservation accounting for btrees we're staging

[Christoph Hellwig <hch@infradead.org>]

The data structure and support code looks fine to me, but I do have
some nitpicky comments and questions:

> -	/* Fork format. */
> -	unsigned int		if_format;
> -
> -	/* Number of records. */
> -	unsigned int		if_extents;
> +	/* Which fork is this btree being built for? */
> +	int			if_whichfork;

The two removed fields seems to be unused even before this patch.
Should they have been in a separate removal patch?

> diff --git a/fs/xfs/scrub/agheader_repair.c b/fs/xfs/scrub/agheader_repair.c
> index 876a2f41b0637..36c511f96b004 100644
> --- a/fs/xfs/scrub/agheader_repair.c
> +++ b/fs/xfs/scrub/agheader_repair.c
> @@ -10,6 +10,7 @@
>  #include "xfs_trans_resv.h"
>  #include "xfs_mount.h"
>  #include "xfs_btree.h"
> +#include "xfs_btree_staging.h"
>  #include "xfs_log_format.h"
>  #include "xfs_trans.h"
>  #include "xfs_sb.h"

I also don't think all the #include churn belongs into this patch,
as the only existing header touched by it is xfs_btree_staging.h,
which means that anything that didn't need it before still won't
need it with the changes.

> +/*
> + * Estimate proper slack values for a btree that's being reloaded.
> + *
> + * Under most circumstances, we'll take whatever default loading value the
> + * btree bulk loading code calculates for us.  However, there are some
> + * exceptions to this rule:
> + *
> + * (1) If someone turned one of the debug knobs.
> + * (2) If this is a per-AG btree and the AG has less than ~9% space free.
> + * (3) If this is an inode btree and the FS has less than ~9% space free.

Where does this ~9% number come from?  Obviously it is a low-space
condition of some sort, but I wonder what are the criteria.  It would
be nice to document that here, even if the answer is
answer is "out of thin air".

> + * Note that we actually use 3/32 for the comparison to avoid division.
> + */
> +static void

> +	/* No further changes if there's more than 3/32ths space left. */
> +	if (free >= ((sz * 3) >> 5))
> +		return;

Is this code really in the critical path that a division (or relying
on the compiler to do the right thing) is out of question?  Because
these shits by magic numbers are really annyoing to read (unlike
say normal SECTOR_SHIFT or PAGE_SHIFT ones that are fairly easy to
read).