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.
