[LTP] [PATCH] ext4: don't set SB_RDONLY after filesystem errors

Theodore Ts'o tytso@mit.edu
Sun Oct 6 05:38:05 CEST 2024


On Fri, Oct 04, 2024 at 03:33:56PM -0400, Gabriel Krisman Bertazi wrote:
> > Regardless of what is right or wrong to do in ext4, I don't think that the test
> > really cares about remount read-only.
> > I don't see anything in the test that requires it. Gabriel?
> > If I remove MS_RDONLY from the test it works just fine.
> 
> If I recall correctly, no, there is no need for the MS_RDONLY.  We only
> care about getting the event to test FS_ERROR.

Looking at ltp/testcases/kernel/syscalls/fanotify/fanotify22.c this
appears to be true.

I'll note though that this comment in fanotify22.c is a bit
misleading:

	/* Unmount and mount the filesystem to get it out of the error state */
	SAFE_UMOUNT(MOUNT_PATH);
	SAFE_MOUNT(tst_device->dev, MOUNT_PATH, tst_device->fs_type, 0, NULL);

Once ext4_error() gets called, the file system will be marked as
containing errors.  This can be seen when you mount the file system,
and when you run fsck -p:

root@kvm-xfstests:~# mount /dev/vdc /vdc
[ 1893.569015] EXT4-fs (vdc): mounted filesystem 9bf1a2df-fc1c-4b46-a8e8-c9e3e9bc7a26 r/w with ordered data mode. Quota mode: none.
root@kvm-xfstests:~# echo "testing 123" > /sys/fs/ext4/vdc/trigger_fs_error 
[ 1907.268249] EXT4-fs error (device vdc): trigger_test_error:129: comm bash: testing 123
root@kvm-xfstests:~# umount /vdc
[ 1919.722934] EXT4-fs (vdc): unmounting filesystem 9bf1a2df-fc1c-4b46-a8e8-c9e3e9bc7a26.
root@kvm-xfstests:~# mount /dev/vdc /vdc
[ 1923.270852] EXT4-fs (vdc): warning: mounting fs with errors, running e2fsck is recommended
[ 1923.297998] EXT4-fs (vdc): mounted filesystem 9bf1a2df-fc1c-4b46-a8e8-c9e3e9bc7a26 r/w with ordered data mode. Quota mode: none.
root@kvm-xfstests:~# umount /vdc
[ 1925.889086] EXT4-fs (vdc): unmounting filesystem 9bf1a2df-fc1c-4b46-a8e8-c9e3e9bc7a26.
root@kvm-xfstests:~# fsck -p /dev/vdc
fsck from util-linux 2.38.1
/dev/vdc contains a file system with errors, check forced.
/dev/vdc: 12/327680 files (0.0% non-contiguous), 42398/1310720 blocks

Unmounting and remounting the file system is not going to clear file
system's error state.  You have to clear the EXT2_ERROR_FS state, and
if you want to prevent fsck.ext4 -p from running, you'll need to set
the EXT2_VALID_FS bit, via 'debugfs -w -R "ssv state 1" /dev/vdc' or
you could just run 'fsck.ext4 -p /dev/vdc'.

Also note that way I generally recommend that people simulate
triggering a file system error is via a command like this:

   echo "test error description" > /sys/fs/ext4/vdc/trigger_fs_error

To be honest, I had completely forgotten that the abort mount option
exists at all, and if I didn't know that ltp was using it, I'd be
inclined to deprecate and remove it....

						- Ted



More information about the ltp mailing list