[PATCH] cifs: Add information about noserverino

[Jeff Layton]

On Thu, 9 Dec 2010 22:58:20 -0600
Steve French <smfrench at gmail.com> wrote:

> On Thu, Dec 9, 2010 at 9:09 PM, Suresh Jayaraman <sjayaraman at suse.de> wrote:
> > On 12/10/2010 02:14 AM, Steve French wrote:
> >> On Thu, Dec 9, 2010 at 1:34 PM, Jeff Layton <jlayton at redhat.com> wrote:
> >>> On Thu, 9 Dec 2010 12:26:39 -0600
> >>> Steve French <smfrench at gmail.com> wrote:
> >>>
> >>>> On Thu, Dec 9, 2010 at 6:09 AM, Jeff Layton <jlayton at redhat.com> wrote:
> >>>>> On Thu, 09 Dec 2010 17:10:28 +0530
> >>>>> Suresh Jayaraman <sjayaraman at suse.de> wrote:
> >>>>>
> >>>>>> On 12/06/2010 09:08 PM, Jeff Layton wrote:
> >>>>>>> On Mon, 06 Dec 2010 16:35:06 +0100
> >>>>>>> Bernhard Walle <bernhard at bwalle.de> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Zitat von Jeff Layton <jlayton at redhat.com>:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 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 at redhat.com>