On Sat, Apr 10, 1999 at 04:43:17AM +0200, Anders Hammarquist wrote:
> A quick look in nfsd/vfs.c revealed that setattr didn't do
> DQUOT_TRANSFER() if the owner changed. The first patch fixes that.
. . .
> The patch is relative 2.2.5 + patches in knfsd-1.2.2
> tarball. (Scott, can you try it please?)
I'll have a look...
> Then, I was also told that files marked for mandatory locking were
> not openable via NFS (even if they weren't regular files). The first
> fix was pretty obvious, make sure the file is a regular file before
> deciding it is marked for mandatory locking.
No. no.. this is so even if file is a DIRECTORY! Marking a
directory as setgid is commonly done to force files and
subdirectories to inheret the parent group ownership. One may
even wish to do this without setting group execute privs on the
directory. This is NOT mandatory locking, because it is a
directory, yet this effectively prunes the whole branch as seen
via knfs!
> The current NFS client refuses to lock files marked for
> mandatory locking (is there a reason other than that locking
> doesn't work well over NFS for this?).
I believe the concern is that mandatory locking can potentialy
HANG a system, since even root will block on a write. Opening
read-only may be safe though... I'm no expert.
> Also, in playing around with the locking I noted that locks on the
> server are independent from locks on the clients. That is, if one
> NFS client locks a file, the lock is seen by other NFS clients.
> However, locks on the server are not seen on the clients, and the
> server doesn't see client locks, so trying to lock a file on
> a client and the server, both obtain a lock! I haven't been able
> to figure out why this is happening though...
Ick... needs to be fixed, but not critical in my application. If
I'm doing file locking via nfs, then the nfs server must be
critical to multiple servers. This means I do not trust it to do
anything BUT nfs, and it therefore should not be locking exported
files.
-smj
-
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/