Stale NFS file handle

Hi,
since 2.6.0-test6 I get "Stale NFS file handle" when transferring huge amounts of data from a nfs-server which is running on -test6.
The client also runs -test6. Transfers from a server running kernel 2.4.22 work flawless.

I use the nfs-kernel-server 1.0.6 on Debian/sid.

---------------------------------------
Malte Schröder
[email protected]
ICQ# 68121508
---------------------------------------

Hi Malte!

Are you using mount options when mounting the NFS volume? I had this problem when I used rsize=8192 and wsize=8192 as nfs mount options. Just left them out and everything was fine again.

Axel

____________________________________________________________________________
Axel Siebenwirth phone +49 3641 776807 |
Am Birnstiel 3 axel at pearbough dot net |
07745 Jena |
Germany________________________________________________http://pearbough.net |

For my birthday I got a humidifier and a de-humidifier... I put them in the same room and let them fight it out.
-- Stephen Wright
____________________________________________________________________________

Does not make a difference .. but there seems to be something wrong in the code as far as I can interpret what I read on this list ... For now I'm using the user-space-deamon .. work's fine :)

---------------------------------------
Malte Schröder
[email protected]
ICQ# 68121508
---------------------------------------

In article <20030928184841.GL532@neon>,
Axel Siebenwirth <[email protected]> wrote:

| Are you using mount options when mounting the NFS volume?
| I had this problem when I used rsize=8192 and wsize=8192 as nfs mount
| options. Just left them out and everything was fine again.

This is useful as a test and problem identification, but if you're transferring significant data between systems other than those directly connected with a low latency connection you do see performance loss.

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Hallo Malte,
Hallo list-members,

my solution for getting a reliable NFS Server with 2.5 kernels was to use "no_subtree_check" in /etc/exports.

(The next thing is pasted, please read below the code)

I stumbled over the following lines of code in fs/nfsd/nfsfh.c:

int nfsd_acceptable(void *expv, struct dentry *dentry)

{
        struct svc_export *exp = expv;
        int rv;
        struct dentry *tdentry;
        struct dentry *parent;

        if (exp->ex_flags & NFSEXP_NOSUBTREECHECK)
                return 1;

        tdentry = dget(dentry);
        while (tdentry != exp->ex_dentry && ! IS_ROOT(tdentry)) {
                /* make sure parents give x permission to user */
                int err;
                parent = dget_parent(tdentry);
                err = permission(parent->d_inode, S_IXOTH, NULL);
                                                  ^^^^^^^ <- !!!!
                if (err < 0) {
                        dput(parent);
                        break;
                }

First, nfsd_acceptable always returns success if subtree_checks are diabled. Second, I think, the line marked above is not correct.

The comment says "give x permission to user", but the call looks suspiciously wrong.

You can also make the error disappear by allowing setting all x bits for "other" from your mount-point down to the directory where the error appears.

Echoing "32767" to /proc/sys/sunrpx/nfs_debug helped me a great deal to find that error.

Cheers,
Patrick

Hallo Malte,

I accidently deleted your original mail. Did you try exporting your filesystems with "no_subtree_check", like this ?

/dvd \
tony.local.net(rw,async,no_subtree_check)

If not, could you please try and tell me if that helps ?

Thanks,
Patrick

This makes the messages go away :)

---------------------------------------
Malte Schröder
[email protected]
ICQ# 68121508
---------------------------------------

I think it is correct, though arguably it should be "MAY_EXEC" rather than "S_IXOTH" (both of which are '1').
The permission call checks if the current user (which is computed from the rpc credentials) has eXecute access to the directories.

Have you actually tried this or are you just assuming?

Presumably you got lots of "nfsd_acceptable failed at ....". Is that correct?

I guess I need to do some testing with "subtree_check" set and see if I can reproduce it.

NeilBrown