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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
