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

[David Sterba <dsterba@suse.cz>]

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'.