Re: [PATCH 1/2] btrfs: Raise nobarrier log level to warn

David Sterba
2025-05-26T09:21:13Z

On Mon, May 26, 2025 at 02:24:54PM +0930, Qu Wenruo wrote:
>
>
> 在 2025/5/26 03:15, Kyoji Ogasawara 写道:
> > Sorry for sending piecemeal updates.
> >
> > I've realized that if the log goes into btrfs_emit_options(), it'll
> > only show up during remount operations.
> >
> > So, I was thinking of adding the following code to open_ctree(), right
> > after the btrfs_check_options() call.
> >
> > if (btrfs_test_opt(fs_info, NOBARRIER))
> > btrfs_info(fs_info, "turning off barriers, use with care");
> >
> > What do you think of this approach?
> >
> > We could also set the log level to warning if that's preferred.
>
> It turns out to be a more deeply involved bug.
>
> The root cause is, we no longer use btrfs_parse_options() to output the
> mount option changes.
>
> Before the fsconfig change, we have btrfs_parse_options() function,
> which will output an info line for each triggered option.
> That function is utilized by both mount (open_ctree()) and remount
> (btrfs_remount())
>
> But with the fsconfig migration, we use parse_param() helper, which now
> only handles the feature setting, no more messaging.
> And btrfs_emit_options() to emit the message line.
>
> The btrfs_emit_options() can handle empty @old context, thus it is
> designed to handle both mount and remount.
>
> Unfortunately at mount time we do not call btrfs_emit_options(), this
> means we lost all the previous mount messages.
>
> I'm not sure if this is intended or not, the fact we didn't notice the
> change until now means, most of the info lines are not that useful and
> no one is really noticing them.
>
> So @josef, is it intended to skip all the mount option related info
> messages? Or it's just a bug?

I don't think this was intentional and it looks like a usability
regression. If it's just changed timing when the options are printed
during mount it may not be serious.

Comparing old and new logs from my VMs, I see the difference now. It
may not be easy to spot as it's the compression messages and seeing at
least some mount messages I don't know what could be missing there.

We should probably reinstate the messages, possibly also removing some
that are not that interesting like 'has skinny extents' or 'checking
UUID tree'.