public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Kyoji Ogasawara <sawara04.o@gmail.com>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs: Raise nobarrier log level to warn
Date: Sat, 24 May 2025 13:18:58 +0930	[thread overview]
Message-ID: <af00227c-c301-4311-b570-47f4d404c499@suse.com> (raw)
In-Reply-To: <CAKNDObChsMqFAYK-QT8DmFEitFX+Pmi7ifGDbYe2GfnPnUr1FQ@mail.gmail.com>



在 2025/5/24 11:51, Kyoji Ogasawara 写道:
> Thanks for the explanation. I understand the issue with btrfs_parse_param()
> being triggered multiple times.
> 
> If I move the log into btrfs_parse_param(), it would currently use
> btrfs_info_if_set(),
> resulting in an info level log.
> 
> Is an info level acceptable for this warning, or would you prefer a
> warn level log?

I think info level is good enough.

As the main purpose of that message line is still just to show we're 
using barrier or not, the extra "use with care" is just something good 
to have.

Thus no need to go warning IMHO.

Thanks,
Qu


> 
> If so, should I create a new helper function like btrfs_warn_if_set()?
> 
> 2025年5月21日(水) 13:13 Qu Wenruo <quwenruo.btrfs@gmx.com>:
>>
>>
>>
>> 在 2025/5/21 12:57, sawara04.o@gmail.com 写道:
>>> From: Kyoji Ogasawara <sawara04.o@gmail.com>
>>>
>>> The nobarrier option disables barriers, improving performance at the cost
>>> of potential data loss during crashes or power failures especially on devices
>>> without reliable write-back caching.
>>> To better reflect this risk, the log level has been raised to warn.
>>>
>>> Signed-off-by: Kyoji Ogasawara <sawara04.o@gmail.com>
>>> ---
>>>    fs/btrfs/super.c | 7 ++++---
>>>    1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
>>> index 7310e2fa8526..012b63a07ab1 100644
>>> --- a/fs/btrfs/super.c
>>> +++ b/fs/btrfs/super.c
>>> @@ -407,10 +407,12 @@ static int btrfs_parse_param(struct fs_context *fc, struct fs_parameter *param)
>>>                }
>>>                break;
>>>        case Opt_barrier:
>>> -             if (result.negated)
>>> +             if (result.negated) {
>>>                        btrfs_set_opt(ctx->mount_opt, NOBARRIER);
>>> -             else
>>> +                     btrfs_warn(NULL, "turning off barriers, use with care");
>>> +             } else {
>>>                        btrfs_clear_opt(ctx->mount_opt, NOBARRIER);
>>> +             }
>>>                break;
>>>        case Opt_thread_pool:
>>>                if (result.uint_32 == 0) {
>>> @@ -1439,7 +1441,6 @@ static void btrfs_emit_options(struct btrfs_fs_info *info,
>>>        btrfs_info_if_set(info, old, NODATASUM, "setting nodatasum");
>>>        btrfs_info_if_set(info, old, SSD, "enabling ssd optimizations");
>>>        btrfs_info_if_set(info, old, SSD_SPREAD, "using spread ssd allocation scheme");
>>> -     btrfs_info_if_set(info, old, NOBARRIER, "turning off barriers");
>>
>> I know you want to avoid duplicated messages about the nobarrier.
>>
>> But it is better to use btrfs_emit_options() to add the warning.
>>
>> The problem of showing the error in btrfs_parse_param() is, it can be
>> triggered multiple times.
>>
>> E.g. mount -o nobarrier,nobarrier,nobarrier $dev $mnt
>>
>> Then there will be 3 lines of "turning of barrier, use with care".
>> But inside btrfs_emit_options() it will be only once.
>>
>> In fact this also affect the warning for excessive commit mount option,
>> but there is no better solution for that option, but we can do better here.
>>
>> Thanks,
>> Qu
> 


  reply	other threads:[~2025-05-24  3:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-21  3:27 [PATCH 0/2] btrfs: Improve logging for barrier-related operation sawara04.o
2025-05-21  3:27 ` [PATCH 1/2] btrfs: Raise nobarrier log level to warn sawara04.o
2025-05-21  4:13   ` Qu Wenruo
2025-05-24  2:21     ` Kyoji Ogasawara
2025-05-24  3:48       ` Qu Wenruo [this message]
2025-05-25  2:32         ` Kyoji Ogasawara
2025-05-25 17:45           ` Kyoji Ogasawara
2025-05-26  4:54             ` Qu Wenruo
2025-05-26  9:21               ` David Sterba
2025-06-11 17:06                 ` Kyoji Ogasawara
2025-05-26  9:14         ` David Sterba
2025-05-21  3:27 ` [PATCH 2/2] btrfs: Fix incorrect log message related barrier sawara04.o
2025-05-21  4:15   ` Qu Wenruo
2025-05-24  2:00     ` Kyoji Ogasawara
2025-05-24  2:09       ` Qu Wenruo
2025-07-21  8:07         ` Kyoji Ogasawara

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=af00227c-c301-4311-b570-47f4d404c499@suse.com \
    --to=wqu@suse.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=sawara04.o@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox