> > Hi Zorro,
> >
> > > > Regression test for:
> > > > a6b3bfe176e8 ext4: fix corruption during on-line resize
> > > >
> > > > Signed-off-by: Srivathsa Dara <srivathsa.d.dara@xxxxxxxxxx>
> > > > ---
> > > > tests/ext4/060 | 43 +++++++++++++++++++++++++++++++++++++++++++
> > > > tests/ext4/060.out | 2 ++
> > > > 2 files changed, 45 insertions(+) create mode 100755
> > > > tests/ext4/060 create mode 100644 tests/ext4/060.out
> > > >
> > > > diff --git a/tests/ext4/060 b/tests/ext4/060 new file mode 100755
> > > > index 00000000..440748ea
> > > > --- /dev/null
> > > > +++ b/tests/ext4/060
> > > > @@ -0,0 +1,43 @@
> > > > +#! /bin/bash
> > > > +# SPDX-License-Identifier: GPL-2.0 # Copyright (c) 2024 Oracle.
> > > > +All Rights Reserved.
> > > > +#
> > > > +# FS QA Test 060
> > > > +#
> > > > +# This test ensures that kernel avoids FS corruption while online
> > > > +# resizing an ext4 filesystem with disabled resize_inode feature.
> > > > +#
> > > > +# The commit a6b3bfe176e8 ("ext4: fix corruption during on-line
> > > > +resize") # stops the corruption.
> > > > +#
> > > > +
> > > > +. ./common/preamble
> > > > +_begin_fstest auto resize quick
> > > > +
> > > > +_supported_fs ext4
> > > > +_fixed_by_kernel_commit a6b3bfe176e8 \
> > > > + "ext4: fix corruption during on-line resize"
> > > > +
> > > > +_require_command "$RESIZE2FS_PROG" resize2fs _require_command
> > > > +"$E2FSCK_PROG" e2fsck _require_scratch_size_nocheck $((9* 1024 *
> > > > +1024))
> > > > +
> > > > +# Initialize an EXT4 filesystem with the resize_inode feature
> > > > +disabled, # and a size of 128MiB less than 8GiB, i.e., short of 1
> > > > +block group in # an 8GiB filesystem.
> > > > +
> > > > +dev_size=$((8* 1024 * 1024 * 1024 - 128 * 1024 * 1024))
> > > > +MKFS_OPTIONS="-O ^resize_inode $MKFS_OPTIONS" _scratch_mkfs_sized $dev_size \
> > > > + >>$seqres.full 2>&1
> > >
> > > Just for sure, is the 8G fs size a necessary requirement to reproduce the bug?
> > > Is it related with the block size (e.g. different blocksize need different fs size for testing)?
> >
> > Yes, the issue was that, before the fix, while performing an online
> > resize of a filesystem with the resize_inode feature disabled, the
> > kernel would corrupt the first block of the last group in the 0th meta_bg.
> >
> > If the block size is 1024, each meta_bg has 16 (1024/64) block groups.
> > The last blockgroup of the 0th meta_bg is 15, and the block that gets
> > corrupted is the 122,880th block, which is the first block of the 15th block group.
> >
> > If the block size is 2048, each meta_bg has 32 (2048/64) block groups.
> > The last blockgroup of the 0th meta_bg is 31, and the block that gets
> > corrupted is the 507,904th block, which is the first block of the 31st block group.
> >
> > If the block size is 4096, each meta_bg has 64 (4096/64) block groups.
> > The last blockgroup of the 0th meta_bg is 63, and the block that gets
> > corrupted is the 2,064,384th block, which is the first block of the 63rd block group.
> >
> > The corruption occurred because, when updating backup group
> > descriptors, the kernel failed to check whether the group descriptor
> > being updated belonged to the meta_bg layout or not, leading to an incorrect block being updated.
> > Hence, the corruption.
> >
> > To reproduce the issue, the initial filesystem's descriptor block must
> > have some available space, and the resize operation should increase
> > the filesystem size enough to cross the meta_bg boundary.
> >
> > In this case, the initial filesystem size was chosen as 8GiB minus
> > 128MiB, so that its descriptor block has space to accommodate an additional block group.
> > The filesystem is then resized to 9GiB ( 8GiB is the meta_bg boundary).
>
> Actually I hope to check the MKFS_OPTIONS with you, I saw you try to carry on the
> MKFS_OPTIONS, MKFS_OPTIONS="-O ^resize_inode $MKFS_OPTIONS". If MKFS_OPTIONS="-b 65536" (or others),
> can this bug still be reproduced? If not, we can drop the old MKFS_OPTIONS, just set
> MKFS_OPTIONS="-O ^resize_inode". Or we can keep it.
I think using just MKFS_OPTIONS="-O ^resize_inode" is a better choice,
thanks for the input.
>
> >
> > >
> > > > +
> > > > +_scratch_mount
> > > > +
> > > > +# Perform online-resize
> > > > +$RESIZE2FS_PROG $SCRATCH_DEV 9G >> $seqres.full 2>&1
> > > > +
> > > > +$E2FSCK_PROG -fn $SCRATCH_DEV >> $seqres.full 2>&1 || _fail "Filesystem corrupted"
> > >
> > > Do you want to test online resize or online fsck or both? (Does ext4
> > > support online fsck?)
> >
> > I want to test only the online resize. No, EXT4 doesn't support online fsck.
> > However, e2fsck with the -fn option reports corruption even if the
> > device is mounted.
>
> As EXT4 doesn't support online fsck, better to unmount before fscking. To avoid other interference.
Sure, will send a v2 with the suggested changes.
>
> Thanks,
> Zorro
>
> >
> > Thanks,
> > Srivathsa
> >
> > >
> > > > +
> > > > +echo "Silence is golden"
> > > > +
> > > > +status=0
> > > > +exit
> > > > diff --git a/tests/ext4/060.out b/tests/ext4/060.out new file mode
> > > > 100644 index 00000000..8ffce4de
> > > > --- /dev/null
> > > > +++ b/tests/ext4/060.out
> > > > @@ -0,0 +1,2 @@
> > > > +QA output created by 060
> > > > +Silence is golden
> > > > --
> > > > 2.39.3
