All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <guaneryu@gmail.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: fstests <fstests@vger.kernel.org>
Subject: Re: [PATCH] misc large filesystem fixes
Date: Thu, 30 Aug 2018 11:19:03 +0800	[thread overview]
Message-ID: <20180830031902.GC3651@desktop> (raw)
In-Reply-To: <b647246c-c206-229a-f801-60f20dfa9f28@redhat.com>

On Wed, Aug 29, 2018 at 04:43:38PM -0500, Eric Sandeen wrote:
> There are a few tests which fail on large filesytems because
> we run into mkfs limits.
> 
> xfs/010 and xfs/013 hardcode 2 AGs, but if the device is larger
> than 2T this will fail.  Check the device size and restrict it
> to just under 2T so that a 2-AG mkfs is possible.
> 
> xfs/178 tries to decrease the agcount and re-mkfs, but if the
> default AG size was chosen to be 1T, decreasing the AG count
> results in too-large AGs and mkfs fails.  The intention here
> AFAICT is to simply re-mkfs with non-overlapping AG headers,
> so increasing the AG count should achieve the same purpose,
> and cause mkfs to choose a smaller-than-default AG size which
> should pass.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> diff --git a/tests/xfs/010 b/tests/xfs/010
> index ee1595c8..2b30c867 100755
> --- a/tests/xfs/010
> +++ b/tests/xfs/010
> @@ -96,7 +96,14 @@ _require_xfs_finobt
>  
>  rm -f $seqres.full
>  
> -_scratch_mkfs_xfs "-m crc=1,finobt=1 -d agcount=2" | _filter_mkfs 2>$seqres.full
> +# If 2 AGs would result in too-large AG size, restrict the size
> +DSIZEOPT=""
> +DEV_SZ=$(blockdev --getsize64 $SCRATCH_DEV)
> +if [ "$DEV_SZ" -ge "$((2*(2**40)))" ]; then
> +  DSIZEOPT="-d size=2047g"
> +fi
> +
> +_scratch_mkfs_xfs "-m crc=1,finobt=1 -d agcount=2 $DSIZEOPT" | _filter_mkfs 2>$seqres.full

I think this kind of problem will happen to all tests that specify a
custom "agcount" in mkfs but without an "agsize" nor "size". For
example, xfs/062 would fail if $SCRATCH_DEV is larger than 8T. I guess
we need a more general way to fix the problem.

I'm thinking to introduce a new helper to require a given agcount will
fit the device size, and if the device is bigger than ($agcount * 1T)
then _notrun the test, something like (may need a better helper name):

_require_xfs_support_agcount()
{
	local dev=$1
	local agcount=$2
	local max_sz=$((agcount*(2**40)))
	local dev_sz=$(blockdev --getsize64 $dev)

	if [ $dev_sz -gt $max_sz ]; then
		_notrun "agcount $agcount is too small to hold $dev_sz device"
	fi
}

Then add this _require rule to all tests that only specify a custom
agsize, e.g. for xfs/010 we could do

_require_xfs_support_agcount $SCRATCH_DEV 2

I roughly went through all xfs tests and found that the following ones
may need this new _require rule

xfs/010
xfs/013
xfs/062
xfs/178
xfs/179
xfs/310

Perhaps there're better ways to solve the problem, any suggestions are
welcomed! 

Thanks,
Eryu

  reply	other threads:[~2018-08-30  7:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-29 21:43 [PATCH] misc large filesystem fixes Eric Sandeen
2018-08-30  3:19 ` Eryu Guan [this message]
2018-08-30  3:30   ` Eric Sandeen
2018-08-30  4:29     ` Eryu Guan
2018-08-30  4:34     ` Dave Chinner
2018-08-31 17:44       ` Eric Sandeen
2018-09-25 19:12 ` [PATCH V2] " Eric Sandeen
2018-10-06 11:15   ` Eryu Guan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180830031902.GC3651@desktop \
    --to=guaneryu@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.