All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Cc: Olga Kornievskaia <aglo@umich.edu>,
	Trond Myklebust <Trond.Myklebust@netapp.com>,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/1] silence-call-timeout-printk
Date: Thu, 27 Mar 2008 16:53:11 -0400	[thread overview]
Message-ID: <20080327205311.GL32540@fieldses.org> (raw)
In-Reply-To: <EXNANE01kO22ZhCl8ai000001cd-kboziUmgGqYSZCGxjG3uujkOHZLvdrmu@public.gmane.org>

On Thu, Mar 27, 2008 at 04:36:50PM -0400, Talpey, Thomas wrote:
> Let me get this straight. You are suggesting that bringing back
> cl_chatty as cl_quiet, in order to print messages when the
> server's callback client can't talk to the client's callback server,
> makes things clear? ;-)

Err, in order *not* to, actually.  (It's pretty easy for callbacks to
fail, especially the initial probe of the callback channel.  I don't
want to spam the server's logs about that.)

> 
> Oh, my head does hurt. :-) :-)

Yeah, OK ,fair enough.

> Seriously, it sounds okay but printk isn't exactly the best means
> for a server to tell people something doesn't work. The issue I see
> is that clients will lose a delegation, data corruption may result,

If the cb_path_down stuff is done conservatively enough, then in theory
there shouldn't be data corruption....

In any case, even if we think losing the callback path is worth a
printk, I still think that other cases (like failing to establish one in
the first case) aren't.

> and the only hint is a message in the server's log? Maybe I'm still
> having trouble with the first question.

So I'd rather we didn't put anything at all in the logs.  (Though
perhaps it could be useful to the administrator to have some optional
way to figure out the callback status if they were e.g. investigating a
performance problem.)

--b.

  parent reply	other threads:[~2008-03-27 20:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-27 18:49 [PATCH 1/1] silence-call-timeout-printk Olga Kornievskaia
2008-03-27 19:54 ` J. Bruce Fields
2008-03-27 20:03   ` Trond Myklebust
     [not found]     ` <1206648229.15396.2.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-03-27 20:23       ` J. Bruce Fields
2008-03-27 20:31         ` Trond Myklebust
     [not found]           ` <1206649882.15396.17.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-03-27 20:45             ` J. Bruce Fields
2008-03-27 20:36         ` Talpey, Thomas
     [not found]           ` <EXNANE01kO22ZhCl8ai000001cd-kboziUmgGqYSZCGxjG3uujkOHZLvdrmu@public.gmane.org>
2008-03-27 20:53             ` J. Bruce Fields [this message]
2008-03-27 20:57               ` Trond Myklebust
2008-03-28 15:57               ` Talpey, Thomas

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=20080327205311.GL32540@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Thomas.Talpey@netapp.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=aglo@umich.edu \
    --cc=linux-nfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.