On 26/2/24 23:23, Eric Sandeen wrote:
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.
A case that I encountered quite a while ago was where (IIRC) a kernel NFS
bug was logged because of the appearance of a new message in the kernel log.
I investigated and explained that what the message said had already been
happening but was not previously logged and the reason the message was now
appearing was due to code changes (the mount api).
At this point it becomes annoying, when the user isn't happy with the
explanation and doesn't quite say so but continues to complain. Admittedly
I didn't say I wasn't going to change it but then I didn't implement the
change and I'm not an NFS maintainer so maybe I should have ignored the
bug ...
It was then I thought the mount api logging needed so more thought and
here we are.
Perhaps, if we had some way to change the log level of messages via
configuration, sysfs perhaps, so that what gets logged to the kernel
log can be better controlled. An additional (or perhaps different scale)
log level that can allow finer grained control of what gets logged might
be sufficient.
TBH I'm not really sure the best way to improve the situation, all I know
is we do need continue to log messages to the kernel log, where appropriate
and we do need a way to ensure all messages are available in the context.
Ian
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
