Re: [PATCH] xfs/015: enlarge the initial fs size

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Thu, Feb 15, 2018 at 04:33:17PM +0800, Eryu Guan wrote:
> On Wed, Feb 14, 2018 at 08:45:32AM -0800, Darrick J. Wong wrote:
> > On Wed, Feb 14, 2018 at 11:24:01PM +0800, Eryu Guan wrote:
> > > On Thu, Jan 04, 2018 at 01:46:26PM +0800, Eryu Guan wrote:
> > > > Kernel commit f59cf5c29919 ("xfs: remove "no-allocation"
> > > > reservations for file creations") is known to cause earlier ENOSPC
> > > > conditions, and xfs/015 is affected in the way that no new file/dir
> > > > can be created in a newly created 16M XFS with both reflink and
> > > > rmapbt enabled, thus xfs/015 fails due to the missing test dirs.
> > > > 
> > > > So enlarge the initial fs size to 32M that we're able to create new
> > 
> > 32M?  I thought this was a 64M -> 128M expansion?
> 
> The final fs size (after growfs) is expanded from 64M to 128M, but we
> need the initial fs size (prior to growfs) to be 32M instead of 16M.

Ahh, ok.  The initial size is doubled (and the test still grows the fs
4x), so we need to double the _require_space.

> 
> > 
> > > > dir/file before growing the filesystem size.
> > > > 
> > > > Signed-off-by: Eryu Guan <eguan@redhat.com>
> > 
> > I don't think this hurts anything, but otoh I couldn't reproduce the
> > failure you're seeing on my setup.
> 
> You need "both reflink and rmapbt enabled", I can still reproduce it
> with v4.16-rc1 kernel with MKFS_OPTIONS="-m reflink=1,rmapbt=1".
> 
> Thanks for reviewing!

Looks ok,
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>

--D