Message-ID: <20101209155627.16d524cd@tlielax.poochiereds.net>
Date:	Thu, 9 Dec 2010 15:56:27 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	Steve French <smfrench@...il.com>
Cc:	Suresh Jayaraman <sjayaraman@...e.de>,
	Bernhard Walle <bernhard@...lle.de>, sfrench@...ba.org,
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cifs: Add information about noserverino

On Thu, 9 Dec 2010 14:44:27 -0600
Steve French <smfrench@...il.com> wrote:

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

It's a workaround for broken applications. Some discomfort is
reasonable, as long as the default is that ino64 is enabled.

-- 
Jeff Layton <jlayton@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists