All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Christoph Hellwig <hch@infradead.org>,
	Jan Prusakowski <jprusakowski@google.com>,
	fstests@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,
	anand.jain@oracle.com, wqu@suse.com, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH] generic/050: handle f2fs as nojournal filesystem
Date: Fri, 17 Apr 2026 00:42:46 -0700	[thread overview]
Message-ID: <aeHkdon2GH8UUkE4@infradead.org> (raw)
In-Reply-To: <aeER8AIJZecuTLIc@zlang-mailbox>

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?


WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Christoph Hellwig <hch@infradead.org>,
	Jan Prusakowski <jprusakowski@google.com>,
	fstests@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,
	anand.jain@oracle.com, wqu@suse.com, Jan Kara <jack@suse.cz>
Subject: Re: [f2fs-dev] [PATCH] generic/050: handle f2fs as nojournal filesystem
Date: Fri, 17 Apr 2026 00:42:46 -0700	[thread overview]
Message-ID: <aeHkdon2GH8UUkE4@infradead.org> (raw)
In-Reply-To: <aeER8AIJZecuTLIc@zlang-mailbox>

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?



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2026-04-17  7:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-10 13:18 [PATCH] generic/050: handle f2fs as nojournal filesystem Jan Prusakowski
2026-04-10 13:18 ` [f2fs-dev] " Jan Prusakowski via Linux-f2fs-devel
2026-04-14  7:57 ` Christoph Hellwig
2026-04-14  7:57   ` [f2fs-dev] " Christoph Hellwig
2026-04-16 16:47   ` Zorro Lang
2026-04-16 16:47     ` [f2fs-dev] " Zorro Lang
2026-04-17  7:42     ` Christoph Hellwig [this message]
2026-04-17  7:42       ` Christoph Hellwig
2026-04-16 16:44 ` Zorro Lang
2026-04-16 16:44   ` [f2fs-dev] " Zorro Lang
2026-04-17  2:59 ` Chao Yu
2026-04-17  2:59   ` Chao Yu via Linux-f2fs-devel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aeHkdon2GH8UUkE4@infradead.org \
    --to=hch@infradead.org \
    --cc=anand.jain@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=jack@suse.cz \
    --cc=jprusakowski@google.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.