On 22/03/29 05:02PM, Ritesh Harjani wrote: > On 22/03/15 09:55AM, Darrick J. Wong wrote: > > On Tue, Mar 15, 2022 at 07:58:58PM +0530, Ritesh Harjani wrote: > > > In certain cases (it is noted with ext4 fast_commit feature) that, replay phase > > > may not delete the right range of blocks (after sudden FS shutdown) > > > due to some operations which depends on inode->i_size (which during replay of > > > an inode with fast_commit could be 0 for sometime). > > > This fstest is added to test for such scenarios for all generic fs. > > > > > > This test case is based on the test case shared via Xin Yin. > > > > > > Signed-off-by: Ritesh Harjani <riteshh@xxxxxxxxxxxxx> > > > --- > > > tests/generic/676 | 72 +++++++++++++++++++++++++++++++++++++++++++ > > > tests/generic/676.out | 7 +++++ > > > 2 files changed, 79 insertions(+) > > > create mode 100755 tests/generic/676 > > > create mode 100644 tests/generic/676.out > > > > > > diff --git a/tests/generic/676 b/tests/generic/676 > > > new file mode 100755 > > > index 00000000..315edcdf > > > --- /dev/null > > > +++ b/tests/generic/676 > > > @@ -0,0 +1,72 @@ > > > +#! /bin/bash > > > +# SPDX-License-Identifier: GPL-2.0 > > > +# Copyright (c) 2022 IBM Corporation. All Rights Reserved. > > > +# > > > +# FS QA Test 676 > > > +# > > > +# This test with ext4 fast_commit feature w/o below patch missed to delete the right > > > +# range during replay phase, since it depends upon inode->i_size (which might not be > > > +# stable during replay phase, at least for ext4). > > > +# 0b5b5a62b945a141: ext4: use ext4_ext_remove_space() for fast commit replay delete range > > > +# (Based on test case shared by Xin Yin <yinxin.x@xxxxxxxxxxxxx>) > > > +# > > > + > > > +. ./common/preamble > > > +_begin_fstest auto shutdown quick log recoveryloop > > > > This isn't a looping recovery test. Maybe we should create a 'recovery' > > group for tests that only run once? I think we already have a few > > fstests like that. > > I gave it a thought, but I feel it might be unncessary. > From a developer/tester perspective who wanted to test anything related to > recovery would then have to use both recovery and recoveryloop. > Thoughts? > > > > > > + > > > +# Override the default cleanup function. > > > +_cleanup() > > > +{ > > > + cd / > > > + rm -r -f $tmp.* > > > + _scratch_unmount > /dev/null 2>&1 > > > > I think the test harness does this for you already, right? Ok, I agree with this. I will remove _scratch_unmount operation from these two new tests in v3. -ritesh