Re: Linux NFS server problem

G. Allen Morris III (gam3@harpo.ixlabs.com)
Wed, 17 Feb 1999 18:52:09 -0800


H.J., I just don't understand the problem that you are trying to solve.
I 2.3.3 of RFC 1094 it stats:

The file handle can contain whatever information the
server needs to distinguish an individual file.

WHATEVER is pretty strong language!
I can see cases where a system might put a timestamp in every
filehandle or a counter. If solaris is complaining because the
NFS filehandle is different between two calls, then it is broken.

APPENDIX

ftp://ftp.isi.edu/in-notes/rfc1094.txt

2.3.3. fhandle

typedef opaque fhandle[FHSIZE];

The "fhandle" is the file handle passed between the server and the
client. All file operations are done using file handles to refer
to a file or directory. The file handle can contain whatever
information the server needs to distinguish an individual file.

>>>H.J. Lu said:
> Hi,
>
> I have been working on the kernel NFS server for the past few days to
> remove the pathname information from the filehandle. I managed to
> get rid of "struct dentry *". Everything seems to work fine. But
> there are still 2 issues unresolved:
>
> 1. There is
>
> __u32 fb_dirino; /* dir inode number */
>
> in the filehandle. That means moving a file to a different directory
> will result in a different filehandle. I'd like to get rid of it.
>
> 2. A related issue is there is no easy way to lookup dentry with
> ino and dev, which prevents me from removing fb_dirino and also
> hurts the NFS server performance.
>
> What is the best way to add a new dcache function:
>
> struct dentry * lookup_dentry_by_inode (kdev_t dev, ino_t ino);
>
> Does anyone have a patch?
>
---------------------------------
G. Allen Morris III

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/