[PATCH] generic/050: handle f2fs as nojournal filesystem

[PATCH] generic/050: handle f2fs as nojournal filesystem

[Jan Prusakowski]

F2FS uses a checkpoint mechanism for metadata consistency rather than a
traditional journal. Roll-forward recovery is only needed if there are
fsync'd files since the last checkpoint.

In this test case, files are created without fsync, so there is no
roll-forward data to replay during mount.

Therefore, F2FS does not need to write to the device to recover, and
successfully mounts on the read-only block device. Thus, it should be
treated as nojournal in this case.

Signed-off-by: Jan Prusakowski <jprusakowski@google.com>
---
 tests/generic/050 | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/tests/generic/050 b/tests/generic/050
index 3bc37175..3a641a65 100755
--- a/tests/generic/050
+++ b/tests/generic/050
@@ -46,6 +46,18 @@ elif [ "$FSTYP" = "btrfs" ]; then
 	# So for this test case, btrfs will not get any dirty log tree thus
 	# it can be treated as "nojournal".
 	features="nojournal"
+elif [ "$FSTYP" = "f2fs" ]; then
+	# F2FS uses a checkpoint mechanism for metadata consistency rather than a
+	# traditional journal. Roll-forward recovery is only needed if there are
+	# fsync'd files since the last checkpoint.
+	#
+	# In this test case, files are created without fsync, so there is no
+	# roll-forward data to replay during mount.
+	#
+	# Therefore, F2FS does not need to write to the device to recover, and
+	# successfully mounts on the read-only block device. Thus, it should be
+	# treated as "nojournal" in this case.
+	features="nojournal"
 fi
 _link_out_file "$features"
 
-- 
2.53.0.1213.gd9a14994de-goog

Re: [PATCH] generic/050: handle f2fs as nojournal filesystem

[Christoph Hellwig]

On Fri, Apr 10, 2026 at 01:18:20PM +0000, Jan Prusakowski wrote:
> F2FS uses a checkpoint mechanism for metadata consistency rather than a
> traditional journal. Roll-forward recovery is only needed if there are
> fsync'd files since the last checkpoint.
> 
> In this test case, files are created without fsync, so there is no
> roll-forward data to replay during mount.
> 
> Therefore, F2FS does not need to write to the device to recover, and
> successfully mounts on the read-only block device. Thus, it should be
> treated as nojournal in this case.

This looks ok, but I always wonder if we want an opt-in for this
"journaling" behavior and/or define it clear in common/.

Re: [PATCH] generic/050: handle f2fs as nojournal filesystem

[Zorro Lang]

On Fri, Apr 10, 2026 at 01:18:20PM +0000, Jan Prusakowski wrote:
> F2FS uses a checkpoint mechanism for metadata consistency rather than a
> traditional journal. Roll-forward recovery is only needed if there are
> fsync'd files since the last checkpoint.
> 
> In this test case, files are created without fsync, so there is no
> roll-forward data to replay during mount.
> 
> Therefore, F2FS does not need to write to the device to recover, and
> successfully mounts on the read-only block device. Thus, it should be
> treated as nojournal in this case.
> 
> Signed-off-by: Jan Prusakowski <jprusakowski@google.com>
> ---
>  tests/generic/050 | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/tests/generic/050 b/tests/generic/050
> index 3bc37175..3a641a65 100755
> --- a/tests/generic/050
> +++ b/tests/generic/050
> @@ -46,6 +46,18 @@ elif [ "$FSTYP" = "btrfs" ]; then
>  	# So for this test case, btrfs will not get any dirty log tree thus
>  	# it can be treated as "nojournal".
>  	features="nojournal"
> +elif [ "$FSTYP" = "f2fs" ]; then
> +	# F2FS uses a checkpoint mechanism for metadata consistency rather than a
> +	# traditional journal. Roll-forward recovery is only needed if there are
> +	# fsync'd files since the last checkpoint.
> +	#
> +	# In this test case, files are created without fsync, so there is no
> +	# roll-forward data to replay during mount.
> +	#
> +	# Therefore, F2FS does not need to write to the device to recover, and
> +	# successfully mounts on the read-only block device. Thus, it should be
> +	# treated as "nojournal" in this case.
> +	features="nojournal"

OK, so f2fs is similar with what btrfs does in this case.

Reviewed-by: Zorro Lang <zlang@kernel.org>

>  fi
>  _link_out_file "$features"
>  
> -- 
> 2.53.0.1213.gd9a14994de-goog
> 
> 

Re: [PATCH] generic/050: handle f2fs as nojournal filesystem

[Zorro Lang]

On Tue, Apr 14, 2026 at 12:57:02AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 10, 2026 at 01:18:20PM +0000, Jan Prusakowski wrote:
> > F2FS uses a checkpoint mechanism for metadata consistency rather than a
> > traditional journal. Roll-forward recovery is only needed if there are
> > fsync'd files since the last checkpoint.
> > 
> > In this test case, files are created without fsync, so there is no
> > roll-forward data to replay during mount.
> > 
> > Therefore, F2FS does not need to write to the device to recover, and
> > successfully mounts on the read-only block device. Thus, it should be
> > treated as nojournal in this case.
> 
> This looks ok, but I always wonder if we want an opt-in for this
> "journaling" behavior and/or define it clear in common/.

_has_traditional_journal ? _has_journal_replay ? :-D

Re: [f2fs-dev] [PATCH] generic/050: handle f2fs as nojournal filesystem

[Chao Yu]

On 4/10/26 13:18, Jan Prusakowski via Linux-f2fs-devel wrote:
> F2FS uses a checkpoint mechanism for metadata consistency rather than a
> traditional journal. Roll-forward recovery is only needed if there are
> fsync'd files since the last checkpoint.
> 
> In this test case, files are created without fsync, so there is no
> roll-forward data to replay during mount.
> 
> Therefore, F2FS does not need to write to the device to recover, and
> successfully mounts on the read-only block device. Thus, it should be
> treated as nojournal in this case.
> 
> Signed-off-by: Jan Prusakowski <jprusakowski@google.com>

Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,

Re: [PATCH] generic/050: handle f2fs as nojournal filesystem

[Christoph Hellwig]

On Fri, Apr 17, 2026 at 12:47:09AM +0800, Zorro Lang wrote:
> > > Therefore, F2FS does not need to write to the device to recover, and
> > > successfully mounts on the read-only block device. Thus, it should be
> > > treated as nojournal in this case.
> > 
> > This looks ok, but I always wonder if we want an opt-in for this
> > "journaling" behavior and/or define it clear in common/.
> 
> _has_traditional_journal ? _has_journal_replay ? :-D

Good question.  We already have _has_metadata_journaling, which is
used in this test and in _require_metadata_journaling.  Unfortunately
no one has bother to describe what behavior it is supposed to guard.

From looking at the _require_metadata_journaling users, it really seems
to be about providing file system consistency after crash.  So maybe
_has_metadata_journaling, should be renamed to this effect?

Now in generic/050 the check patched here is used to select the golden
output.  When I wrote the test originally (I can't even remember that),
it was a XFS-specific test, and Jan then later tested it to add this
_has_metadata_journaling check, which also needed further btrfs
workarounds.  AFAICS it is all about failing the mount if log recovery
is required, but the underlying block device is read-only.  So maybe
name it after that?