There is a descrepancy between the fsck flags for ext4 during
filesystem repair and filesystem checking which causes occasional test
failures. In particular, _check_generic_filesystems uses -f for force
checking, but _repair_scratch_fs does not. In some tests, such as
generic/441, we sometimes exit fsck repair early with the filesystem
being deemed "clean" but then _check_generic_filesystems finds issues
during the forced full check. Bringing these flags in sync fixes the
flakes.
Signed-off-by: Leah Rumancik <leah.rumancik@gmail.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
*)
local dev=$SCRATCH_DEV
local fstyp=$FSTYP
+ local fsopts=
if [ $FSTYP = "overlay" -a -n "$OVL_BASE_SCRATCH_DEV" ]; then
_repair_overlay_scratch_fs
# Fall through to repair base fs
fstyp=$OVL_BASE_FSTYP
_unmount $OVL_BASE_SCRATCH_MNT
fi
- # Let's hope fsck -y suffices...
- fsck -t $fstyp -y $dev 2>&1
+ if [[ "$FSTYP" =~ ext[234]$ ]]; then
+ fsopts="-f"
+ fi
+
+ fsck -t $fstyp -y ${fsopts} $dev 2>&1
local res=$?
case $res in
$FSCK_OK|$FSCK_NONDESTRUCT|$FSCK_REBOOT)
res=$?
;;
*)
- # Let's hope fsck -y suffices...
- fsck -t $FSTYP -y $TEST_DEV >$tmp.repair 2>&1
+ local fsopts=
+ if [[ "$FSTYP" =~ ext[234]$ ]]; then
+ fsopts="-f"
+ fi
+ fsck -t $FSTYP -y ${fsopts} $TEST_DEV >$tmp.repair 2>&1
res=$?
if test "$res" -lt 4 ; then
res=0