Locking over NFS was added somewhere in the 2.1.x line. The 2.0.35
kernels would silently report that the file was locked, even though it
was not. Applications dependent on locking could therefore corrupt
their files.
To make locking work with 2.1.x, you must run the portmap and rpc.statd
daemons. portmap comes with Red Hat. rpc.statd can be found in the
latest knfsd package from H.J.Lu. (You _only_ need statd, not the other
programs). You must also be running statd and and lockd on the file
server.
To get the same behaviour as with 2.0.35, you can mount your NFS
filesystem with the "nolock" option. See `man 8 mount'. Note that if
your application does locking, it probably needs locking to be enabled
to make it reliable. Locking does, however, slow down access.
You should also upgrade to kernel 2.1.131 to make file locking over NFS
work properly. Some changes were made recently to make locks interact
sensibly with file cacheing.
-- Jamie
On Wed, Dec 09, 1998 at 12:16:04PM -0800, HYIN.US.ORACLE.COM wrote:
> we have a problem running an application built on 2.0.35 redhat. The
> application
> is running fine on 2.0.35, but not on the new kernel 2.1.129.
>
> our application is failing in fcntl(), for some reason.
>
> the system call tracing shows this output.
>
> fcntl(17, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1
> ENOLCK (No locks available)
-
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/