Message-ID: <20251022012550.GP6170@frogsfrogsfrogs>
Date: Tue, 21 Oct 2025 18:25:50 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Dave Dykstra <dwd@...n.ch>
Cc: 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:
> 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
> 
> 

Powered by blists - more mailing lists