Re: surprise behavior #1: ENOENT for existing directories

On Wed, 09 Dec 2009 10:31:23 +0530
Suresh Jayaraman <[email protected]> wrote:

> On 12/09/2009 01:07 AM, aaron brick wrote:
> > suresh and jeff,
> > i am happy to report no such problems since remounting with
> > noserverino. this must be some kind of miracle option.
> > 
> > does it cost much in performance terms to locally assign inode numbers
> > like this? i don't know why my NAS is getting them wrong (?), but
> > given the results, this is something i really needed.
> > 
> 
> I don't think there will be an noticable performance impact (though
> there might be some impact when generating unique inode number for a
> large number of inodes). On the upside a call to the server is avoided.
> However, there is no choice but to use 'noserverino' option if the
> server doesn't guarantee unique inode numbers.
> 

With unix extensions enabled, the cost of "serverino" is virtually nil.
Without unix extensions there is some cost to fetching server inode
numbers, but it shouldn't be too terrible. The main downside to not
using server inode numbers is that you can't detect hardlinks. What
we're finding though is that there is a lot of server-side bugginess in
this area. We've been slowly working on fixes that should make
disabling of server inode numbers more automatic.

One question I have -- we had some fixes go into the kernel for these
sorts of problems very late in the 2.6.32 cycle. If you boot a 2.6.32
kernel (an actual release, not an rc kernel), is this problem still
reproducible when you mount w/o "noserverino"?

-- 
Jeff Layton <[email protected]>