On Thu, 9 Dec 2010 22:58:20 -0600 Steve French <smfrench@xxxxxxxxx> wrote: > On Thu, Dec 9, 2010 at 9:09 PM, Suresh Jayaraman <sjayaraman@xxxxxxx> wrote: > > On 12/10/2010 02:14 AM, Steve French wrote: > >> On Thu, Dec 9, 2010 at 1:34 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > >>> On Thu, 9 Dec 2010 12:26:39 -0600 > >>> Steve French <smfrench@xxxxxxxxx> wrote: > >>> > >>>> On Thu, Dec 9, 2010 at 6:09 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > >>>>> On Thu, 09 Dec 2010 17:10:28 +0530 > >>>>> Suresh Jayaraman <sjayaraman@xxxxxxx> wrote: > >>>>> > >>>>>> On 12/06/2010 09:08 PM, Jeff Layton wrote: > >>>>>>> On Mon, 06 Dec 2010 16:35:06 +0100 > >>>>>>> Bernhard Walle <bernhard@xxxxxxxxx> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> Zitat von Jeff Layton <jlayton@xxxxxxxxxx>: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> 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) > >> > >> I think that NFS did it that way because of the way that superblocks are shared between vfsmounts. It would be impossible to share a sb between two vfsmounts with two different settings. I won't object to a new mount option for it if that's the concensus. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
