Joern Engel <[email protected]> writes:
> For consoles like netconsole and blockconsole the loglevel filtering
> really doesn't make any sense. If a line gets printed at all, please
> send it down to that console, no questions asked.
Could you please explain this a bit further? Why wouldn't you want to
allow the admin to filter log messages to the block or network console?
This doesn't make a whole lot of sense to me, and in fact could cause
problems for netconsole now that you're potentially sending a ton more
traffic over the wire.
Cheers,
Jeff
On Fri, Mar 01, 2013 at 09:52:27AM -0500, Jeff Moyer wrote:
> > For consoles like netconsole and blockconsole the loglevel filtering
> > really doesn't make any sense. If a line gets printed at all, please
> > send it down to that console, no questions asked.
>
> Could you please explain this a bit further? Why wouldn't you want to
> allow the admin to filter log messages to the block or network console?
> This doesn't make a whole lot of sense to me, and in fact could cause
> problems for netconsole now that you're potentially sending a ton more
> traffic over the wire.
Let's reverse the question: why would the admin ever want to filter
messages to debugging consoles like netconsole or blockconsole?
When running a debugging session, you generally want to see *all*
messages.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Borislav Petkov <[email protected]> writes:
> On Fri, Mar 01, 2013 at 09:52:27AM -0500, Jeff Moyer wrote:
>> > For consoles like netconsole and blockconsole the loglevel filtering
>> > really doesn't make any sense. If a line gets printed at all, please
>> > send it down to that console, no questions asked.
>>
>> Could you please explain this a bit further? Why wouldn't you want to
>> allow the admin to filter log messages to the block or network console?
>> This doesn't make a whole lot of sense to me, and in fact could cause
>> problems for netconsole now that you're potentially sending a ton more
>> traffic over the wire.
>
> Let's reverse the question: why would the admin ever want to filter
> messages to debugging consoles like netconsole or blockconsole?
>
> When running a debugging session, you generally want to see *all*
> messages.
People don't just use this for "debugging sessions." They use it in
production, and I already gave you one reason why you might not want to
do this with netconsole (udp is unreliable, and I've definitely seem
cases where netconsole suffered due to dropped packets; this won't make
that better, especially when you multiply the extra bytes times the
number of servers on the subnet).
Cheers,
Jeff
On Fri, Mar 01, 2013 at 10:08:00AM -0500, Jeff Moyer wrote:
> People don't just use this for "debugging sessions." They use it in
> production, and I already gave you one reason why you might not want
> to do this with netconsole (udp is unreliable, and I've definitely
> seem cases where netconsole suffered due to dropped packets; this
> won't make that better, especially when you multiply the extra bytes
> times the number of servers on the subnet).
Ok, so we probably need to drop 4/9 for netconsole.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Borislav Petkov <[email protected]> writes:
> On Fri, Mar 01, 2013 at 10:08:00AM -0500, Jeff Moyer wrote:
>> People don't just use this for "debugging sessions." They use it in
>> production, and I already gave you one reason why you might not want
>> to do this with netconsole (udp is unreliable, and I've definitely
>> seem cases where netconsole suffered due to dropped packets; this
>> won't make that better, especially when you multiply the extra bytes
>> times the number of servers on the subnet).
>
> Ok, so we probably need to drop 4/9 for netconsole.
I don't think you've provided a very strong case for ignoring the
administrator's configuration settings. I'm against the patches that
introduce this behaviour, for whatever that's worth (2 cents is the
going rate, I think).
Cheers,
Jeff
On Fri, Mar 01, 2013 at 10:42:16AM -0500, Jeff Moyer wrote:
> I don't think you've provided a very strong case for ignoring the
Maybe you should've looked at the 5/9 commit message - there's your
strong case.
> administrator's configuration settings. I'm against the patches that
> introduce this behaviour, for whatever that's worth (2 cents is the
> going rate, I think).
I'm fine with netconsole retaining old behavior since people reportedly
use it not only as a debugging console.
blockconsole, OTOH, is purely a debugging console and has to log
*everything* *out-of-the-box* once the block device is plugged in. No
configuration, no user intervention, no admin fiddling with whatever.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Fri, 1 March 2013 10:08:00 -0500, Jeff Moyer wrote:
>
> People don't just use this for "debugging sessions." They use it in
> production, and I already gave you one reason why you might not want to
> do this with netconsole (udp is unreliable, and I've definitely seem
> cases where netconsole suffered due to dropped packets; this won't make
> that better, especially when you multiply the extra bytes times the
> number of servers on the subnet).
I think I maintain a fairly sizeable production setup with netconsole.
A few hundred machines run netconsole and send all messages to a
single recipient. And all those machines have the patch we are
discussing applied. That has caused roughly zero problems so far.
We constantly see problems with netconsole and presumably packet loss
(haven't checked yet) when show_state() runs. That amount of load
appears to be too much for the network. Regular production netconsole
is utterly unimpressed in my network, with or without CON_ALLDATA.
Which is not to say you are wrong. It just means that noone has shown
an example supporting your argument yet, while I have one supporting
mine.
More fundamentally, I believe the console log levels used to make
sense when systems had exactly one console. With multiple consoles
and vastly different properties of those consoles, you simply cannot
find one good answer for all. A 9600 baud serial console will usually
add several seconds to your boot process, so eliminating extra
messages is hugely important. Blockconsole can take several megabytes
a second without blinking, so the cost of extra messages is near-zero,
while the benefit remains identical.
Maybe the correct solution would be to have a separate loglevel for
each console. I don't know. For my purposes the coarser CON_ALLDATA
approach is good enough.
Jörn
--
"Security vulnerabilities are here to stay."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001