All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <guan@eryu.me>
To: Theodore Ts'o <tytso@mit.edu>
Cc: fstests@vger.kernel.org, Eric Whitney <enwlinux@gmail.com>
Subject: Re: [PATCH] ext4/033: remove a portion of the test assuming resize2fs would fail
Date: Sun, 19 Dec 2021 23:16:45 +0800	[thread overview]
Message-ID: <Yb9M3aIb9cJGIJaB@desktop> (raw)
In-Reply-To: <20211215035409.244674-1-tytso@mit.edu>

On Tue, Dec 14, 2021 at 10:54:09PM -0500, Theodore Ts'o wrote:
> The ext4/033 test tries to test if resize2fs would fail when resizing
> a file system to a size that the number of inodes exceeds the maximum
> allowed inode size, 2**32-1.  This no longer takes place as of
> e2fsprogs commit 623985ed7dd5 ("resize2fs: attempt to keep the # of
> inodes valid by removing the last bg") which will allow resizing a
> file system to 64TB by reducing the last block group so that file
> system will be 64TB - 128MB, which is close enough for government
> work.
> 
> Reported-by: Eric Whitney <enwlinux@gmail.com>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
>  tests/ext4/033     | 8 --------
>  tests/ext4/033.out | 1 -
>  2 files changed, 9 deletions(-)
> 
> diff --git a/tests/ext4/033 b/tests/ext4/033
> index 1bc14c03..0fd0ec90 100755
> --- a/tests/ext4/033
> +++ b/tests/ext4/033
> @@ -66,14 +66,6 @@ _mount $DMHUGEDISK_DEV $SCRATCH_MNT
>  echo "Initial fs dump" >> $seqres.full
>  $DUMPE2FS_PROG -h $DMHUGEDISK_DEV >> $seqres.full 2>&1
>  
> -# This should fail, s_inodes_count would just overflow!
> -echo "Resizing to inode limit + 1..."
> -$RESIZE2FS_PROG $DMHUGEDISK_DEV $((limit_groups*group_blocks)) >> $seqres.full 2>&1
> -if [ $? -eq 0 ]; then
> -	echo "Resizing succeeded but it should fail!"
> -	exit
> -fi

This portion of test is the key of the original regression test, if
we're going to remove this part, does it make sense to remove ext4/033
completely?

Thanks,
Eryu

> -
>  # This should succeed, we are maxing out inodes
>  echo "Resizing to max group count..."
>  $RESIZE2FS_PROG $DMHUGEDISK_DEV $(((limit_groups-1)*group_blocks)) >> $seqres.full 2>&1
> diff --git a/tests/ext4/033.out b/tests/ext4/033.out
> index 24c251cb..183a7492 100644
> --- a/tests/ext4/033.out
> +++ b/tests/ext4/033.out
> @@ -1,6 +1,5 @@
>  QA output created by 033
>  Figure out block size
>  Format huge device
> -Resizing to inode limit + 1...
>  Resizing to max group count...
>  Resizing to device size...
> -- 
> 2.31.0

  reply	other threads:[~2021-12-19 15:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15  3:54 [PATCH] ext4/033: remove a portion of the test assuming resize2fs would fail Theodore Ts'o
2021-12-19 15:16 ` Eryu Guan [this message]
2021-12-20 20:39   ` Theodore Ts'o
2021-12-20 20:40   ` [PATCH] ext4/033: test EXT4_IOC_RESIZE_FS by calling the ioctl directly Theodore Ts'o
2022-01-05 15:57     ` Zorro Lang
2022-01-05 16:06       ` Zorro Lang
2022-01-05 20:02         ` Theodore Ts'o
2022-01-06  2:35           ` Zorro Lang

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=Yb9M3aIb9cJGIJaB@desktop \
    --to=guan@eryu.me \
    --cc=enwlinux@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.