Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756249Ab0LJE6X (ORCPT ); Thu, 9 Dec 2010 23:58:23 -0500 Received: from mail-bw0-f45.google.com ([209.85.214.45]:46543 "EHLO mail-bw0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754258Ab0LJE6W convert rfc822-to-8bit (ORCPT ); Thu, 9 Dec 2010 23:58:22 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HnamwpEZLOfi+ejpO/tP0q05rdLdrli/foFJHRw6tre7zv1OCeNo/mFFs0rR1Sa+Rh Nd1+jN3N/V2gztFgS0DAeEsPQXhdF96aV65ObXtaokDIfZJgq4qwHKyRH8FU9TwgnmFf TwnIfAIgj3NCAUJ3Cg5IObXQy04vtyIBbkkyE= MIME-Version: 1.0 In-Reply-To: <4D0199E2.8030006@suse.de> 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> <4D00C02C.4070006@suse.de> <20101209070952.24793c23@barsoom.rdu.redhat.com> <20101209143448.5c479e50@barsoom.rdu.redhat.com> <4D0199E2.8030006@suse.de> Date: Thu, 9 Dec 2010 22:58:20 -0600 Message-ID: Subject: Re: [PATCH] cifs: Add information about noserverino From: Steve French To: Suresh Jayaraman Cc: Jeff Layton , Bernhard Walle , sfrench@samba.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4592 Lines: 110 On Thu, Dec 9, 2010 at 9:09 PM, Suresh Jayaraman wrote: > On 12/10/2010 02:14 AM, Steve French wrote: >> On Thu, Dec 9, 2010 at 1:34 PM, Jeff Layton wrote: >>> On Thu, 9 Dec 2010 12:26:39 -0600 >>> Steve French wrote: >>> >>>> On Thu, Dec 9, 2010 at 6:09 AM, Jeff Layton wrote: >>>>> On Thu, 09 Dec 2010 17:10:28 +0530 >>>>> Suresh Jayaraman wrote: >>>>> >>>>>> 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? >>>>>> >>>>> My poing was mainly that there's nothing special about CIFS in this >>>>> regard, other than the fact that servers regularly send us inodes that >>>>> are larger than 2^32. Why should we do this for cifs but not for nfs, >>>>> xfs, ext4, etc? >>>>> >>>>> The filldir function gets a dentry as an argument, so it could >>>>> reasonably generate a printk for this. I'm also not keen on >>>>> the printk recommending noserverino for this. That has its own >>>>> drawbacks. >>>>> >>>>> A cFYI for this sort of thing seems reasonable however. >>>> >>>> I agree that a cFYI is reasonable. �The next obvious question is: do >>>> we need to add code to generate unique 32 bit inode numbers >>>> that don't collide (as IIRC Samba does by xor the high and low 32 >>>> bits of the inode number) when the app can't support ino64 >>>> I would prefer not to go back to noserverino since that has worse >>>> drawbacks. >>>> >>> >>> Right, the fact that noserverino works around this is really just due >>> to an implementation detail of iunique(). That should probably be >>> discouraged as a solution since it's not guaranteed to be a workaround >>> in the future. >>> >>> If we did add such a switch, I'd suggest that we pattern it after what >>> NFS did for this. They added an "enable_ino64" module parameter a >>> couple of years ago that defaults to "true". > > What are the advantages we have by making it a module parameter as > opposed to an mount option? XFS seems to have "inode64" mount option for > quite sometime now, without much issues.. I prefer mount option, but with the default to support 64 bit inode numbers. >> makes me uncomfortable to break ino64 for all mounts - when we >> may have one application on one mount that needs it (might be >> better to make a mount related) >> >> > > > -- > Suresh Jayaraman > -- Thanks, Steve -- 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/