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).
