Dear all,
rpc.lockd in FreeBSD suffers from a pubic server's lazyness --- It says it's
done the job, but never did anything besides talking...
Searching through the lists gives different stories. Some say that NFS locking
isn't really necessary, but what about locking critical situations like
de
[-current mailing list pruned; I think -hackers is enough]
> I would like to see it in both -current and -stable.
I think that would be wrong, at least given the current state of
the lockd stuff.
First off, as David himself points out, there are issues with this
code and we'd be well off dealin
* Jordan Hubbard <[EMAIL PROTECTED]> [001214 16:11] wrote:
> [-current mailing list pruned; I think -hackers is enough]
>
> > I would like to see it in both -current and -stable.
>
> I think that would be wrong, at least given the current state of
> the lockd stuff.
>
> First off, as David hims
> David did say that it pretty much works, and preliminary reports
> from a while back started getting him some feedback which quickly
> died off after people forgot about the announcement.
The only confirmed bug (reported from Drew Gallatin @ Duke) appears to be a
result of broken RPC64. I _thou
Hello,
I've recently seen in the NetBSD 1.5 release Notes that *they* claim to
have a fully functional rpc.lockd manager : "Server part of NFS locking
(implemented by rpc.lockd(8)) now works."
could someone have a look at what our cousins have done and perhaps
import it in -current ?
Tf
I pruned the Cc: list a bit...
One of the email messages that you quoted has the URL for the latest
development of the lockd code. As far as tests go it appears to be mostly
complete (there appears to be an issue with RPC64 on little endian machines,
but I have not yet had a chance to crawl thro
* David E. Cross <[EMAIL PROTECTED]> [001214 14:45] wrote:
> I pruned the Cc: list a bit...
>
> One of the email messages that you quoted has the URL for the latest
> development of the lockd code. As far as tests go it appears to be mostly
> complete (there appears to be an issue with RPC64 on
Going with the lockd code on builder is great with me. The last I had
looked it had some of the same issues as the lockd developed here (no
handling of grace periods, etc.), so on a featureset we are even. The rpics
lockd has the advantage of being known by some of us to a much greater extent
th
I'm not going to take such an action w/o the blessing of -core. :)
--
David Cross | email: [EMAIL PROTECTED]
Lab Director | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Compute
On Fri, Dec 15, 2000 at 12:09:32AM +0100, Thierry Herbelot wrote:
> Hello,
>
> I've recently seen in the NetBSD 1.5 release Notes that *they* claim to
> have a fully functional rpc.lockd manager : "Server part of NFS locking
> (implemented by rpc.lockd(8)) now works."
>
> could someone have a lo
:I'm not going to take such an action w/o the blessing of -core. :)
:
:--
:David Cross | email: [EMAIL PROTECTED]
:Lab Director | Rm: 308 Lally Hall
In regards to Jordan's message just a moment ago... you know, I *total*
forgot t
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
David,
I wrote the NFS lockd code for BSD/OS (it's based on some user land
stuff Keith Bostic did, and then Kirk McKusick helped clean up my
basic design and the VFS layering for the server/kernel side).
It has passed the connectathon tests, and has been being
used by BSD/OS customers for a whi
In the last episode (Dec 16), Axel Thimm said:
> 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 mom
On Sat, Dec 16, 2000 at 04:26:58PM -0600, Dan Nelson wrote:
> That's why dotlocking is recommended for locking mail spools. Both
> procmail and mutt will dotlock your mail file while it's being
> accessed.
Or Maildirs.
--
Jos Backus _/ _/_/_/"Modularity is not a hack."
Don Coleman wrote:
>
> David,
>
> I wrote the NFS lockd code for BSD/OS (it's based on some user land
> stuff Keith Bostic did, and then Kirk McKusick helped clean up my
> basic design and the VFS layering for the server/kernel side).
We have an application that is desperately in need o
On Sat, Dec 16, 2000 at 04:27:20PM -0600, Dan Nelson wrote:
> In the last episode (Dec 16), Axel Thimm said:
> > 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),
17 matches
Mail list logo