> After releasing knfsd 1.3, I found a NFS locking bug. But I haven't
> tracked down where the bug is. I export /var/spool/mail. I have
> -rw------- 1 hjl mail 115263 May 9 10:49 /var/spool/mail/hjl
Sounds to me like the second part of the problem I reported in the last week.
See if changing the file to be world readable fixes it ...
> My server is running Linux 2.2.7 plus knfsd 1.3 and client is running
> 2.2.7 plus knfsd 1.3. I tend to think NFS locking is broken.
Agreed -- it's the nlmsvc_ops->fopen call that's the problem ...
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <5135.926277850.2@cl.cam.ac.uk>
Content-Description: forwarded message
To: Linux Kernel <linux-kernel@vger.rutgers.edu>
Subject: Known problems with Linux 2.2.* and knfsd 0.4.22 ?
In-reply-to: Your message of Mon, 03 May 1999 21:11:20 -0700.
<199905040411.VAA03200@Harpo.ixlabs.com>
Date: Tue, 04 May 1999 14:12:12 +0100
From: Piete Brooks <Piete.Brooks@cl.cam.ac.uk>
Message-Id: <E10eezd-0002YU-00@heaton.cl.cam.ac.uk>
Exec summary: Are there known problems with knfsd 0.4.22 quota on truncation ?
Also: should locking work on non world readable files ?
Fully gory details ....
I have knfsd 0.4.22 on Linux 2.2.[0-7], basically for the user land
programmes. I find it really hard to keep track of which bits of knfsd are std
in the kernel, which bits are "optional" patches to add new features (like NFS
V3), which bits are bug fixes, and which bits are required patches.
This has resulted in me using out of date (0.4.22 vs 1.2) knfsd user space
commands. No problem, except that it appears that if a file is truncated
(rather than deleted) over NFS, the amount of space marked as `used' by that
user does not go down.
Is this a known problem ? Will knfsd 1.2 fix it ? If so, what patches do I
need to apply to 2.2.7 ?
Also, I find that whereas locking works in general, I have instances when a
simple remote perl lock command fails if the file being locked (e.g. a .mail
file) isn't world readable :-(
It appears that when nlm_lookup_file calls nlmsvc_ops->fopen, current->fsuid
is (for *SOME* clients hosts) set to "nobody", rather the actual user, with
the result that locking fails. Ideas ?
-
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/
------- =_aaaaaaaaaa0--
-
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/