Re: [PATCH V3 06/19] Fix xfs/139 to work with 64k block size

[Chandan Rajendra <chandan@linux.vnet.ibm.com>]

On Tuesday, September 18, 2018 3:59:18 AM IST Darrick J. Wong wrote:
> On Wed, Sep 12, 2018 at 11:56:13AM +0530, Chandan Rajendra wrote:
> > For 64k block size, the agsize provided in the test causes mkfs.xfs to
> > fail due to insufficient log space. Hence this commit computes agsize
> > based on block size of the filesystem.
> > 
> > Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> > ---
> >  tests/xfs/139     | 15 +++++++++------
> >  tests/xfs/139.out |  8 ++++++--
> >  2 files changed, 15 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tests/xfs/139 b/tests/xfs/139
> > index 2a26635..9ab74c8 100755
> > --- a/tests/xfs/139
> > +++ b/tests/xfs/139
> > @@ -34,17 +34,20 @@ _require_cp_reflink
> >  
> >  rm -f $seqres.full
> >  
> > +_scratch_mkfs >/dev/null 2>&1
> > +_scratch_mount
> > +blksz=$(_get_block_size $SCRATCH_MNT)
> > +_scratch_unmount
> > +
> >  echo "Format and mount"
> > -_scratch_mkfs -d agsize=$((32 * 1048576)) > $seqres.full 2>&1
> > +_scratch_mkfs -d agsize=$((4400 * $blksz)) > $seqres.full 2>&1
> 
> Uh... how did this magic 4400 number come about?  I'd have expected
> 8192...?

Sorry, I should have added a comment describing the reasoning behind using 4400.
And now, I have forgotten the rational behind choosing 4400 blocks. Most likely
it was to keep the AG size smaller when using 64k block size. The test requires
that file1 occupy enough blocks to overflow an AG and then CoW-ing the same
would cause ENOSPC when expanding the per-AG refcntbt if a bug exists in
the Per-AG reservation.

I will post another version of this patchset which uses 8192 blocks as the 
AG size.

-- 
chandan