[PATCH] fuse2fs: updates for message reporting journal is not supported

[PATCH] fuse2fs: updates for message reporting journal is not supported

[Dave Dykstra]

This makes two changes to the message that is shown saying that fuse2fs
does not support the journal.  First is that it reverts the check to
what it was before 3875380 to look at the ro option not being set
instead of checking the RW flag.  That's because I don't think this
message needs to be shown when the ro option is set even when it was
opened RW; there should be nothing to corrupt when it is ro.

Second, it changes the message to say that writing is not supported
rather than using the journal is not supported.  The current message is
confusing because in fact the journal is used for recovery when needed
and possible.

Also submitted as PR https://github.com/tytso/e2fsprogs/pull/251

Signed-off-by: Dave Dykstra <2129743+DrDaveD@users.noreply.github.com>
---
 misc/fuse2fs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c
index cb5620c7..c46cc03b 100644
--- a/misc/fuse2fs.c
+++ b/misc/fuse2fs.c
@@ -4774,10 +4774,10 @@ int main(int argc, char *argv[])
 		}
 	}
 
-	if (global_fs->flags & EXT2_FLAG_RW) {
+	if (!fctx.ro) {
 		if (ext2fs_has_feature_journal(global_fs->super))
 			log_printf(&fctx, "%s",
- _("Warning: fuse2fs does not support using the journal.\n"
+ _("Warning: fuse2fs does not support writing the journal.\n"
    "There may be file system corruption or data loss if\n"
    "the file system is not gracefully unmounted.\n"));
 		err = ext2fs_read_inode_bitmap(global_fs);
-- 
2.43.5

Re: [PATCH] fuse2fs: updates for message reporting journal is not supported

[Darrick J. Wong]

On Thu, Oct 16, 2025 at 03:09:03PM -0500, Dave Dykstra wrote:
> This makes two changes to the message that is shown saying that fuse2fs
> does not support the journal.  First is that it reverts the check to
> what it was before 3875380 to look at the ro option not being set
> instead of checking the RW flag.  That's because I don't think this
> message needs to be shown when the ro option is set even when it was
> opened RW; there should be nothing to corrupt when it is ro.
> 
> Second, it changes the message to say that writing is not supported
> rather than using the journal is not supported.  The current message is
> confusing because in fact the journal is used for recovery when needed
> and possible.
> 
> Also submitted as PR https://github.com/tytso/e2fsprogs/pull/251
> 
> Signed-off-by: Dave Dykstra <2129743+DrDaveD@users.noreply.github.com>
> ---
>  misc/fuse2fs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c
> index cb5620c7..c46cc03b 100644
> --- a/misc/fuse2fs.c
> +++ b/misc/fuse2fs.c
> @@ -4774,10 +4774,10 @@ int main(int argc, char *argv[])
>  		}
>  	}
>  
> -	if (global_fs->flags & EXT2_FLAG_RW) {
> +	if (!fctx.ro) {

Again, rw != EXT2_FLAG_RW.

The ro and rw mount options specify if the filesystem mount is writable.
You can mount a filesystem in multiple places, and some of the mounts
can be ro and some can be rw.

EXT2_FLAG_RW specifies that the filesystem driver can write to the block
device.  fuse2fs should warn about incomplete journal support any time
the **filesystem** is writable, independent of the write state of the
mount.

Filesystems are allowed to write to the block device even if the mount
itself is readonly, e.g. kernel ext4 recovering the journal on an ro
mount.

NAK.

--D

>  		if (ext2fs_has_feature_journal(global_fs->super))
>  			log_printf(&fctx, "%s",
> - _("Warning: fuse2fs does not support using the journal.\n"
> + _("Warning: fuse2fs does not support writing the journal.\n"
>     "There may be file system corruption or data loss if\n"
>     "the file system is not gracefully unmounted.\n"));
>  		err = ext2fs_read_inode_bitmap(global_fs);
> -- 
> 2.43.5
> 
> 

Re: [PATCH] fuse2fs: updates for message reporting journal is not supported

[Dave Dykstra]

On Fri, Oct 17, 2025 at 12:18:00PM -0700, Darrick J. Wong wrote:
> On Thu, Oct 16, 2025 at 03:09:03PM -0500, Dave Dykstra wrote:
> > This makes two changes to the message that is shown saying that fuse2fs
> > does not support the journal.  First is that it reverts the check to
> > what it was before 3875380 to look at the ro option not being set
> > instead of checking the RW flag.  That's because I don't think this
> > message needs to be shown when the ro option is set even when it was
> > opened RW; there should be nothing to corrupt when it is ro.
> > 
> > Second, it changes the message to say that writing is not supported
> > rather than using the journal is not supported.  The current message is
> > confusing because in fact the journal is used for recovery when needed
> > and possible.
> > 
> > Also submitted as PR https://github.com/tytso/e2fsprogs/pull/251
> > 
> > Signed-off-by: Dave Dykstra <2129743+DrDaveD@users.noreply.github.com>
> > ---
> >  misc/fuse2fs.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c
> > index cb5620c7..c46cc03b 100644
> > --- a/misc/fuse2fs.c
> > +++ b/misc/fuse2fs.c
> > @@ -4774,10 +4774,10 @@ int main(int argc, char *argv[])
> >  		}
> >  	}
> >  
> > -	if (global_fs->flags & EXT2_FLAG_RW) {
> > +	if (!fctx.ro) {
> 
> Again, rw != EXT2_FLAG_RW.
> 
> The ro and rw mount options specify if the filesystem mount is writable.
> You can mount a filesystem in multiple places, and some of the mounts
> can be ro and some can be rw.
> 
> EXT2_FLAG_RW specifies that the filesystem driver can write to the block
> device.  fuse2fs should warn about incomplete journal support any time
> the **filesystem** is writable, independent of the write state of the
> mount.

Are you saying that is indeed possible for a read-only mount to cause
file corruption or data loss if there's not a graceful unmount?  If so,
it sure seems like that should be avoided if possible!  Since fuse2fs
does not support writing the journal, perhaps its behavior should be
different than the kernel's behavior for this too.  Perhaps once the
journal is recovered it should be remounted without EXT2_FLAG_RW.

In any case, during further testing I did find a serious problem with
this change in that it changes more than just the message; it also skips
reading in the inode bitmap, which causes a problem later.  So at
minimum this patch should only affect the message, not the rest of the
stuff in that if statement.

> Filesystems are allowed to write to the block device even if the mount
> itself is readonly, e.g. kernel ext4 recovering the journal on an ro
> mount.
> 
> NAK.
> 
> --D
> 
> >  		if (ext2fs_has_feature_journal(global_fs->super))
> >  			log_printf(&fctx, "%s",
> > - _("Warning: fuse2fs does not support using the journal.\n"
> > + _("Warning: fuse2fs does not support writing the journal.\n"

What do you think about this message change?

Dave

> >     "There may be file system corruption or data loss if\n"
> >     "the file system is not gracefully unmounted.\n"));
> >  		err = ext2fs_read_inode_bitmap(global_fs);
> > -- 
> > 2.43.5
> > 
> > 
> 

Re: [PATCH] fuse2fs: updates for message reporting journal is not supported

[Darrick J. Wong]

On Fri, Oct 17, 2025 at 03:09:57PM -0500, Dave Dykstra wrote:
> On Fri, Oct 17, 2025 at 12:18:00PM -0700, Darrick J. Wong wrote:
> > On Thu, Oct 16, 2025 at 03:09:03PM -0500, Dave Dykstra wrote:
> > > This makes two changes to the message that is shown saying that fuse2fs
> > > does not support the journal.  First is that it reverts the check to
> > > what it was before 3875380 to look at the ro option not being set
> > > instead of checking the RW flag.  That's because I don't think this
> > > message needs to be shown when the ro option is set even when it was
> > > opened RW; there should be nothing to corrupt when it is ro.
> > > 
> > > Second, it changes the message to say that writing is not supported
> > > rather than using the journal is not supported.  The current message is
> > > confusing because in fact the journal is used for recovery when needed
> > > and possible.
> > > 
> > > Also submitted as PR https://github.com/tytso/e2fsprogs/pull/251
> > > 
> > > Signed-off-by: Dave Dykstra <2129743+DrDaveD@users.noreply.github.com>
> > > ---
> > >  misc/fuse2fs.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c
> > > index cb5620c7..c46cc03b 100644
> > > --- a/misc/fuse2fs.c
> > > +++ b/misc/fuse2fs.c
> > > @@ -4774,10 +4774,10 @@ int main(int argc, char *argv[])
> > >  		}
> > >  	}
> > >  
> > > -	if (global_fs->flags & EXT2_FLAG_RW) {
> > > +	if (!fctx.ro) {
> > 
> > Again, rw != EXT2_FLAG_RW.
> > 
> > The ro and rw mount options specify if the filesystem mount is writable.
> > You can mount a filesystem in multiple places, and some of the mounts
> > can be ro and some can be rw.
> > 
> > EXT2_FLAG_RW specifies that the filesystem driver can write to the block
> > device.  fuse2fs should warn about incomplete journal support any time
> > the **filesystem** is writable, independent of the write state of the
> > mount.
> 
> Are you saying that is indeed possible for a read-only mount to cause
> file corruption or data loss if there's not a graceful unmount?  If so,

No, I'm saying that filesystem drivers can *themselves* write metadata
to a filesystem mounted ro.  ro means that user programs can't write to
the files under a particular mountpoint.  This has long been the case
for the kernel implementations of ext*, XFS, btrfs, etc.

I've said this three times now, and this is the last time I'm going to
say it.

> it sure seems like that should be avoided if possible!  Since fuse2fs
> does not support writing the journal, perhaps its behavior should be
> different than the kernel's behavior for this too.  Perhaps once the
> journal is recovered it should be remounted without EXT2_FLAG_RW.

No.  Ted and I are trying to minimize the differences between the kernel
and fuse2fs.

> In any case, during further testing I did find a serious problem with
> this change in that it changes more than just the message; it also skips
> reading in the inode bitmap, which causes a problem later.  So at
> minimum this patch should only affect the message, not the rest of the
> stuff in that if statement.

Are you running fstests QA on these patches before you send them out?

--D

> > Filesystems are allowed to write to the block device even if the mount
> > itself is readonly, e.g. kernel ext4 recovering the journal on an ro
> > mount.
> > 
> > NAK.
> > 
> > --D
> > 
> > >  		if (ext2fs_has_feature_journal(global_fs->super))
> > >  			log_printf(&fctx, "%s",
> > > - _("Warning: fuse2fs does not support using the journal.\n"
> > > + _("Warning: fuse2fs does not support writing the journal.\n"
> 
> What do you think about this message change?
> 
> Dave
> 
> > >     "There may be file system corruption or data loss if\n"
> > >     "the file system is not gracefully unmounted.\n"));
> > >  		err = ext2fs_read_inode_bitmap(global_fs);
> > > -- 
> > > 2.43.5
> > > 
> > > 
> > 
> 

Re: [PATCH] fuse2fs: updates for message reporting journal is not supported

[Dave Dykstra]

On Fri, Oct 17, 2025 at 04:25:21PM -0700, Darrick J. Wong wrote:
> On Fri, Oct 17, 2025 at 03:09:57PM -0500, Dave Dykstra wrote:
> > On Fri, Oct 17, 2025 at 12:18:00PM -0700, Darrick J. Wong wrote:
...
> > > > -	if (global_fs->flags & EXT2_FLAG_RW) {
> > > > +	if (!fctx.ro) {
> > > 
> > > Again, rw != EXT2_FLAG_RW.
> > > 
> > > The ro and rw mount options specify if the filesystem mount is writable.
> > > You can mount a filesystem in multiple places, and some of the mounts
> > > can be ro and some can be rw.
> > > 
> > > EXT2_FLAG_RW specifies that the filesystem driver can write to the block
> > > device.  fuse2fs should warn about incomplete journal support any time
> > > the **filesystem** is writable, independent of the write state of the
> > > mount.
> > 
> > Are you saying that is indeed possible for a read-only mount to cause
> > file corruption or data loss if there's not a graceful unmount?  If so,
> 
> No, I'm saying that filesystem drivers can *themselves* write metadata
> to a filesystem mounted ro.  ro means that user programs can't write to
> the files under a particular mountpoint.  This has long been the case
> for the kernel implementations of ext*, XFS, btrfs, etc.

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?

> I've said this three times now, and this is the last time I'm going to
> say it.

I understood what you said but I'm asking about the implications.

...
> 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?

Dave

Re: [PATCH] fuse2fs: updates for message reporting journal is not supported

[Darrick J. Wong]

On Tue, Oct 21, 2025 at 05:33:35PM -0500, Dave Dykstra wrote:
> On Fri, Oct 17, 2025 at 04:25:21PM -0700, Darrick J. Wong wrote:
> > On Fri, Oct 17, 2025 at 03:09:57PM -0500, Dave Dykstra wrote:
> > > On Fri, Oct 17, 2025 at 12:18:00PM -0700, Darrick J. Wong wrote:
> ...
> > > > > -	if (global_fs->flags & EXT2_FLAG_RW) {
> > > > > +	if (!fctx.ro) {
> > > > 
> > > > Again, rw != EXT2_FLAG_RW.
> > > > 
> > > > The ro and rw mount options specify if the filesystem mount is writable.
> > > > You can mount a filesystem in multiple places, and some of the mounts
> > > > can be ro and some can be rw.
> > > > 
> > > > EXT2_FLAG_RW specifies that the filesystem driver can write to the block
> > > > device.  fuse2fs should warn about incomplete journal support any time
> > > > the **filesystem** is writable, independent of the write state of the
> > > > mount.
> > > 
> > > Are you saying that is indeed possible for a read-only mount to cause
> > > file corruption or data loss if there's not a graceful unmount?  If so,
> > 
> > No, I'm saying that filesystem drivers can *themselves* write metadata
> > to a filesystem mounted ro.  ro means that user programs can't write to
> > the files under a particular mountpoint.  This has long been the case
> > for the kernel implementations of ext*, XFS, btrfs, etc.
> 
> 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?

Yes.  If the vfs mount becomes rw, then fuse2fs will start receiving
requests to change files on the filesystem after a journal recovery.
Notice how there's no code in fuse2fs to receive notifications of ro->rw
or rw->ro transitions?  That's because the fuse driver doesn't send any.

>                                                               That is,
> in the case of ro when there is write access, does the warning message
> really apply?

Yes.  util-linux has done that for a long time, because MS_RDONLY (aka
the flag that gets passed in when a mount fails with EACCES) both sets
the mountpoint to ro and also allows read-only block devices.  It's a
strange artifact of 1990s Linux.

> > I've said this three times now, and this is the last time I'm going to
> > say it.
> 
> I understood what you said but I'm asking about the implications.
> 
> ...
> > 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

You could ask Ted, since you were clearly in communication with him on
github.

"Hi.  I would like to send a patch.  What are the community norms for
generating patch submissions?  Who else should I be asking questions of?
How is QA done on filesystem driver code?"

> 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).

https://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git/

> 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?

https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/

Or, since fstests has never been ported to fuse2fs you'll need my
patched version:

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=fuse2fs_2025-10-21

--D

> Dave
> 
> 

Re: [PATCH] fuse2fs: updates for message reporting journal is not supported

[Theodore Tso]

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
						

Re: [PATCH] fuse2fs: updates for message reporting journal is not supported

[Darrick J. Wong]

On Tue, Oct 21, 2025 at 06:36:05PM -0700, Theodore Tso wrote:
> 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.

/me notes that (as I pointed out elsewhere in the thread) the fuse
server isn't notified if a mount goes from ro -> rw, so fuse2fs really
ought to print the warning unconditionally.

--D

> > > 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
> 						
>