linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org,
	David Howells <dhowells@redhat.com>,
	Alexander Viro <aviro@redhat.com>,
	Bill O'Donnell <billodo@redhat.com>, Karel Zak <kzak@redhat.com>
Subject: Re: [PATCH RFC] vfs: always log mount API fs context messages to dmesg
Date: Mon, 26 Feb 2024 09:23:35 -0600	[thread overview]
Message-ID: <4d5f6969-8abc-443a-a395-d511b4baa99e@redhat.com> (raw)
In-Reply-To: <20240226-geboxt-absitzen-57467986b708@brauner>

On 2/26/24 5:27 AM, Christian Brauner wrote:
>> * systemd is currently probing with a dummy mount option which will
>>   generate noise, see
>>   https://github.com/systemd/systemd/blob/main/src/basic/mountpoint-util.c#L759
>>   i.e. - 
>>   [   10.689256] proc: Unknown parameter 'adefinitelynotexistingmountoption'
>>   [   10.801045] tmpfs: Unknown parameter 'adefinitelynotexistingmountoption'
>>   [   11.119431] proc: Unknown parameter 'adefinitelynotexistingmountoption'
>>   [   11.692032] proc: Unknown parameter 'adefinitelynotexistingmountoption'
> 
> Yeah, I remember that they want to know whether a given mount option is
> supported or not. That would potentially cause some people to pipe up
> complaining about dmesg getting spammed with this if we enable it.
> 
> Ok, so right now invalfc() is logged in the fs_context but it isn't
> logged in dmesg, right? Would it make sense to massage invalfc() so that
> it logs with error into the fs_context but with info into dmesg? This
> would avoid spamming dmesg and then we could risk turning this on to see
> whether this causes complaints.

Hm, yeah that would make sense I think - less consequential messages go only
to the fc, higher priority messages go to both fc and dmesg. (userspace
could still filter on severity for messages in the fc as desired.)

The interfaces are already a little unclear, ("what is warnf vs. warnfc?")
without reading the code, and this'd be another slightly unexpected wrinkle,
but functionally it makes sense to me. I wonder if a sysctl to set a
severity threshold for dmesg would make any sense, or if that'd be overkill.

> You know you could probably test your patch with xfstests to see if this
> causes any new test failures because dmesg contains new output. This
> doesn't disqualify the patch ofc it might just useful to get an idea how
> much noiser we are by doing this.

Good point. Ok, it sounds like there's some movement towards agreement that
at least some messages should go to dmesg. I'll dig a little deeper and come
up with a more solid & tested proposal.

Thanks,
-Eric


  reply	other threads:[~2024-02-26 15:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-22 15:22 [PATCH RFC] vfs: always log mount API fs context messages to dmesg Eric Sandeen
2024-02-22 15:58 ` Bill O'Donnell
2024-02-22 16:08   ` Darrick J. Wong
2024-02-23 15:56     ` Christian Brauner
2024-02-24  1:58       ` Darrick J. Wong
2024-02-26 10:51         ` Christian Brauner
2024-02-23 15:06 ` Christian Brauner
2024-02-23 16:27   ` Eric Sandeen
2024-02-26 11:21     ` Christian Brauner
2024-02-26  9:04   ` Karel Zak
2024-02-27  1:27   ` Kent Overstreet
2024-02-26 11:27 ` Christian Brauner
2024-02-26 15:23   ` Eric Sandeen [this message]
2024-02-27  1:21     ` Ian Kent

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=4d5f6969-8abc-443a-a395-d511b4baa99e@redhat.com \
    --to=sandeen@redhat.com \
    --cc=aviro@redhat.com \
    --cc=billodo@redhat.com \
    --cc=brauner@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).