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 <[email protected]> --- 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 _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
