From: Tom Talpey <tom@talpey.com>
To: Steve French <smfrench@gmail.com>
Cc: CIFS <linux-cifs@vger.kernel.org>,
samba-technical <samba-technical@lists.samba.org>
Subject: Re: [PATCH][smb3 client] log less confusing message on multichannel mounts to Samba when no interfaces returned
Date: Mon, 3 Oct 2022 10:21:50 -0400 [thread overview]
Message-ID: <d7bf66c8-0695-a239-4bfb-d234241479ac@talpey.com> (raw)
In-Reply-To: <CAH2r5msDX4eaGuyine__ePtOTRoSBDjiUN_dthaHpiA9UKm0yg@mail.gmail.com>
On 10/3/2022 12:38 AM, Steve French wrote:
> On Sat, Oct 1, 2022 at 6:22 PM Tom Talpey <tom@talpey.com> wrote:
>>
>> On 10/1/2022 12:54 PM, Steve French wrote:
>>> Some servers can return an empty network interface list so, unless
>>> multichannel is requested, no need to log an error for this, and
>>> when multichannel is requested on mount but no interfaces, log
>>> something less confusing. For this case change
>>> parse_server_interfaces: malformed interface info
>>> to
>>> empty network interface list returned by server
>>
>> Will this spam the log if it happens on every MC refresh (10 mins)?
>> It might be helpful to identify the servername, too.
>
> Yes - I just noticed that in this case (multichannel mount to Samba
> where no valid interfaces) we log it every ten minutes.
> Maybe best way to fix this is to change it to a log once error (with
> server name is fine with me) since it is probably legal to return an
> empty list (so not serious enough to be worth logging every ten
> minutes) and in theory server could fix its interfaces later.
Ten minutes is the default recommended polling interval in the doc.
While it's odd, it's not prevented by the protocol. I could guess
that a server running in a namespace might return strange things
as devices came and went, for example.
It's not an error, so the message is purely informational. It is
useful though. Is it possible to suppress the logging if the
message *doesn't* change, but otherwise emit new ones? That might
require some per-server fiddling to avoid multiple servers flipping
the message.
A boolean or bit in the server struct? A little ugly for the purpose,
but surfacing multichannel events - especially ones that prevent it
from happening - seems worthwhile.
Tom.
Tom.
>>> Cc: <stable@vger.kernel.org>
>>> Signed-off-by: Steve French <stfrench@microsoft.com>
>>>
>>> See attached patch
>>>
>
>
>
next prev parent reply other threads:[~2022-10-03 14:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-01 16:54 [PATCH][smb3 client] log less confusing message on multichannel mounts to Samba when no interfaces returned Steve French
2022-10-01 23:22 ` Tom Talpey
2022-10-03 4:38 ` Steve French
2022-10-03 14:21 ` Tom Talpey [this message]
2022-10-03 22:32 ` Steve French
2022-10-03 22:36 ` Steve French
2022-10-11 19:39 ` Tom Talpey
2022-10-12 4:32 ` Steve French
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=d7bf66c8-0695-a239-4bfb-d234241479ac@talpey.com \
--to=tom@talpey.com \
--cc=linux-cifs@vger.kernel.org \
--cc=samba-technical@lists.samba.org \
--cc=smfrench@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