Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754431Ab0LILks (ORCPT ); Thu, 9 Dec 2010 06:40:48 -0500 Received: from victor.provo.novell.com ([137.65.250.26]:47613 "EHLO victor.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752143Ab0LILkq (ORCPT ); Thu, 9 Dec 2010 06:40:46 -0500 Message-ID: <4D00C02C.4070006@suse.de> Date: Thu, 09 Dec 2010 17:10:28 +0530 From: Suresh Jayaraman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6 MIME-Version: 1.0 To: Jeff Layton CC: Bernhard Walle , sfrench@samba.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cifs: Add information about noserverino References: <1291568855-22604-1-git-send-email-bernhard@bwalle.de> <20101206095725.78422138@tlielax.poochiereds.net> <20101206101214.52a24415@tlielax.poochiereds.net> <20101206163506.56232lqqhc5c3co4@webmail.df.eu> <20101206103836.0714369a@tlielax.poochiereds.net> In-Reply-To: <20101206103836.0714369a@tlielax.poochiereds.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2045 Lines: 51 On 12/06/2010 09:08 PM, Jeff Layton wrote: > On Mon, 06 Dec 2010 16:35:06 +0100 > Bernhard Walle wrote: > >> >> Zitat von Jeff Layton : >> >>> >>> I'm still not sure I like this patch however. It potentially means a >>> lot of printk spam since these things have no ratelimiting. It also >>> doesn't tell me anything about which server might be giving me grief. >>> >>> Maybe this should be turned into a cFYI? >> >> Well, if I see it in the kernel log, it doesn't matter if it's info or >> something else. >> >>> The bottom line though is that running 32-bit applications that were >>> built without -D_FILE_OFFSET_BITS=64 on a 64-bit kernel is a very bad >>> idea. It would be nice to be able to alert users that things aren't >>> working the way they expect, but I'm not sure this is the right place >>> to do that. >> >> Well, but there *are* such application (in my case it was Softmaker Office >> which is a proprietary word processor) and it's quite nice if you know >> how you can workaround it when you encounter such a problem. That's all. >> > > Sure...but this problem is not limited to CIFS. Many modern filesystems > use 64-bit inodes. Running this application on XFS or NFS for instance > is likely to give you the same trouble. You just hit it on CIFS because > the server happened to give you a very large inode number. > > If we're going to add printk's for this situation, it probably ought to > be in a more generic place. > By generic place, did you mean at the VFS level? I think at VFS level, there is little information about the Server or underlying fs and this information doesn't seem too critical that VFS should warn/care much about. May be sticking to a cFYI along with Server detail is a good idea? -- Suresh Jayaraman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/