Thank you, this answers things perfectly ...
On Mon, 4 Apr 2011, Chuck Swiger wrote:
On Apr 4, 2011, at 12:37 PM, Marc G. Fournier wrote:
Okay, next question ... if lockd is running, should fcntl locks work? My read
of the NFS_README.html above indicates to me that they should ... but if that
is the case, then it comes back to why doesn't it?
If rpc.lockd was bug-free and didn't suffer from an inherent design mismatch
between NFS being stateless (prior to NFSv4, anyway) and locking being
stateful, then sure, fcntl locking should work as well on an NFS filesystem as
it does on a local UFS filesystem.
In practice, rpc.lockd is infamously buggy. For that matter, fnctl-style
locking is also fairly broken per SysV/POSIX mandate:
" This interface follows the completely stupid semantics of System V and
IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks associated
with a file for a given process are removed when any file descriptor for
that file is closed by that process. This semantic means that applica-
tions must be aware of any files that a subroutine library may access.
For example if an application for updating the password file locks the
password file database while making the update, and then calls
getpwname(3) to retrieve a record, the lock will be lost because
getpwname(3) opens, reads, and closes the password database. The data-
base close will release all locks that the process has associated with
the database, even if the library routine never requested a lock on the
database. Another minor semantic problem with this interface is that
locks are not inherited by a child process created using the fork(2)
function. The flock(2) interface has much more rational last close
semantics and allows locks to be inherited by child processes. Flock(2)
is recommended for applications that want to ensure the integrity of
their locks when using library routines or wish to pass locks to their
children. Note that flock(2) and fcntl(2) locks may be safely used con-
currently."
Regards,
--
-Chuck
----
Marc G. Fournier Hub.Org Hosting Solutions S.A.
scra...@hub.org http://www.hub.org
Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scra...@hub.org
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
