Message-ID: <20251022013605.GC6859@macsyma-3.local>
Date: Tue, 21 Oct 2025 18:36:05 -0700
From: "Theodore Tso" <tytso@....edu>
To: Dave Dykstra <dwd@...n.ch>
Cc: "Darrick J. Wong" <djwong@...nel.org>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] fuse2fs: updates for message reporting journal is not
 supported

On Tue, Oct 21, 2025 at 05:33:35PM -0500, Dave Dykstra wrote:
> I understood that, but does the filesystem actually write metadata after
> the journal is recovered, such that if the fuse2fs process dies without
> a clean unmount there might be file corruption or data loss?  That is,
> in the case of ro when there is write access, does the warning message
> really apply?

As an example, if file system inconsistencies is detected by the
kernel, it will update various fields in the superblock to indicate
that file system is corrupted, as well as when and where the
corruption is detected:

	__le32	s_error_count;		/* number of fs errors */
	__le32	s_first_error_time;	/* first time an error happened */
	__le32	s_first_error_ino;	/* inode involved in first error */
	__le64	s_first_error_block;	/* block involved of first error */
	__u8	s_first_error_func[32] __nonstring;	/* function where the error happened */
	__le32	s_first_error_line;	/* line number where error happened */
	__le32	s_last_error_time;	/* most recent time of an error */
	__le32	s_last_error_ino;	/* inode involved in last error */
	__le32	s_last_error_line;	/* line number where error happened */
	__le64	s_last_error_block;	/* block involved of last error */
	__u8	s_last_error_func[32] __nonstring;	/* function where the error happened */

Since this is a singleton 4k update the superblock, we don't really
need to worry about problems caused by a non-atomic update of this
metadata.  And similarly, with the journal replay, if we get
interrupted while doing the journal replay, the replay is idempotent,
so we can just restart the journal replay from scratch.

As far as the warning message, if you mean the warning message printed
by fuse2fs indicating that it doen't have journal support, and so if
you are modifying the file system and the system or fuse2fs crashes,
there may be file system corruption and/or data loss, that only needs
to be printed when mounting read-write.  It should be safe to skip
printing that warning message if the file system is mounted with -o
ro, based on the resoning abovce.

> > Are you running fstests QA on these patches before you send them out?
> 
> I had not heard of them, and do not see them documented anywhere in
> e2fsprogs, so I don't know how I was supposed to have known they were
> needed.  Ideally there would be an automated CI test suite.  The patches
> have passed the github CI checks (which don't show up in the standard
> pull request place, but I found them in my own repo's Actions tab).
> 
> Are you talking about the tests at https://github.com/btrfs/fstests?
> If so, it looks like there are a ton of options.  Is there a standard
> way to run them with fuse2fs?

This is btrfs's local form of https://github.com/btrfs/fstests of
xfstests (or fstests, as it is now sometimes called).  We do have an
automated way of running them for ext4 kernel code.   See [1][2]

[1] https://thunk.org/gce-xfstests
[2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md

Darrick has been doing a lot of really good work to run fuse2fs using
fstests/xfstests.  There isn't a turnkey way of running fuse2fs using
this test suite yet.  It's on my todo list to add an easy way to do
this via kvm-xfstests/gce-xfstests but I'm probably not going to get
to it until sometime next year.  If someone would like to give it a
try --- patches would be gratefully accepted.

						- Ted
						

Powered by blists - more mailing lists