Thanks for the fast reply.
On Thu, Dec 14, 2000 at 05:45:15PM -0500, David E. Cross wrote:
> As for "client" vs. "server", that is quite tricky.... since WRT NFS locking
> they are both client and server. The "server" side is done and requires no
> modifcations to the kernel. However a FreeBSD kernel is still unable to
> acquire an NFS lock. This latter case is quite likely what your users are
> seeing the affects of.
Just to understand it right: The current rpc.lockd is neither requesting
locks, if FreeBSD is an NFS client to whatever NFS server, nor serving such
requests as an NFS server to whatever client.
Your (David Cross's) uncommited code does implement NFS locks for a FreeBSD
NFS server. Perhaps in a development stage, but better than not having locks
Now I am quite surprised to learn that FreeBSD apparently is not able to
request locks over NFS. Am I right?
Wouldn't that mean, that you might cause data corruption if, say, I was to
read my mail from a FreeBSD box over an NFS mounted spool directory (running
under OSF1 in our case), and I decided to write back the mbox to the spool dir
the same moment new mail is delivered?
I can't imagine that, I must have misunderstood something, most probably the
role of the client part of NFS locks. Could someone clarify? If I were right,
then FreeBSD would only be good for read only NFS access, and we were using
FreeBSD as NFS clients in our department since before 2.2.x.
> In the end: the code is there and available for those who want to test and
> play with it. It has not been committed because it is still "broken".
> I could do it to -current or make it a port, if someone were to tell me that
> it would be "ok" to do so.
I would vote for port.
P.S. please reply not only to freebsd-hackers, but also Cc: me, as I am only
subscribed to freebsd-current and freebsd-stable.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message