Re: rpc.lockd and true NFS locks?
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 of client side NFS locks, so I'm highly motivated to test this out if it can be ported to either -stable or -current. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
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), and I decided to write back the mbox to the spool dir the same moment new mail is delivered? That's why dotlocking is recommended for locking mail spools. Both procmail and mutt will dotlock your mail file while it's being accessed. This was just a test case above. Not all programs are kind enough to allow control of their locking strategy. What about samba accessing NFS volumes in a transparent net or pure sendmail w/o procmail? Especially if your mail server is already at heavy load serving O(1000) users, forcing each incomming mail to be passed to procmail would must certainly increase the load too much. (Maybe sendmail and samba can also be compiled with dotlocking methods, these are also just examples). Also not all our users want to switch to mutt, we have to support a wide range of mail readers. Axel. -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
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 at all. 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. Thanks, Axel. P.S. please reply not only to freebsd-hackers, but also Cc: me, as I am only subscribed to freebsd-current and freebsd-stable. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
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 while, but mostly for locking mail files (why they don't use POP or IMAP, I've never been able to figure out), and locking files being edited by vi over an NFS export. I think we've had 1 bug report/fix, at least that got back to me ... it's been in BSD/OS for like 2 years now, but given the lack of bug reports, I doubt it's limits are being pushed. The main feature the BSD/OS lockd code is missing, is the client side of server side recovery... BSD/OS never crashes ;-, so our clients have never reported this problem (we mention it in our man page). If the lockd server crashes/reboots, we do go through a grace period, and we notify the clients they need to re-establish their locks, but our client side doesn't track the current lock states (even though the client kernel has that complete information, the user mode lock daemon on the client side doesn't keep a copy). So a BSD/OS server, with non-BSD/OS clients is fully functional. This problem isn't hard to fix... there is a two step fix, all user-land. First, make the client side user level lockd a single process (under BSD/OS, it is two processes)... the problem is that each process has a piece of the responsibility/knowledge you need to re-establish locks on your server when it crashes. Second, the client side user level lockd needs to be able to figure out what lockd locks the client as a whole has been given... the lockd client needs to keep it's own idea of what lock the client still holds (just keep it in memory, ordered by server, simple and quick). I already have the first part done, it just hasn't been fully tested, and since BSD/OS is customer driven, and no customers have been pushing us, I haven't committed it. Anyone who wants it, let me know, and I'll give it to you. There are also some improvements I'd suggest as you merge the code (a pair of fresh eyes and fingers is always an opportunity!) 1) we use a FIFO to pass data from the kernel to the user land process. we should at least use a socket... 2) we use a private field in the proc structure, even though it is only used by the lockd process... this was so we could clean up all the server side data if the user level process of the server side lockd crashed or was killed (Solaris admins kill lockd all the time). Using a kernel level on_exit(), or perhaps making a lockd vfs (so a lockd_close() would be called when the lockd process exits), are both possibilities. The general idea is that if you kill and restart the lockd process, it should behave just as if the server was rebooted. And of course there are the little stuff, like we don't back-off and re-try as well as we should, and errors can be dropped, and little stuff like that. I'd be happy to answer any questions, and help in any way I can. don ps: I'll be travelling in South East Asia (Bangkok, Mayanmar, Bali) from Jan 9 to Feb 15, so I will not be able to help during that time... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
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 moment new mail is delivered? That's why dotlocking is recommended for locking mail spools. Both procmail and mutt will dotlock your mail file while it's being accessed. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
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." _/ _/ _/-- D. J. Bernstein _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
[-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 dealing with those *before* committing it to -stable. I also don't think that this would be achieved simply by having more eyes on it, as you intimate, but by actually having a coherent set of code to work on and the Right Developers(tm) hacking on it. I agree with Bill Joy's assertion that all bugs are NOT shallow through having enough eyes, as Linus likes to say, but through having one or two really bright people practically killing themselves to fix them. We've also had working NFS lockd code in the BSD/OS tree on builder, along with full permission to grab it, for some time now but that hasn't made it happen because the right developers have yet to take that active an interest. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
* 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 himself points out, there are issues with this code and we'd be well off dealing with those *before* committing it to -stable. I also don't think that this would be achieved simply by having more eyes on it, as you intimate, but by actually having a coherent set of code to work on and the Right Developers(tm) hacking on it. I agree with Bill Joy's assertion that all bugs are NOT shallow through having enough eyes, as Linus likes to say, but through having one or two really bright people practically killing themselves to fix them. My argument against this is that giving ample warning is a far cry from the Linux mantra "release early, release often, ship the system with async files, we'll let them know how to not loose data _next_ time". Here I'm proposing that we be more than honest. The current fake lockd doesn't even do fake NLMv4 locks (although there's patches that I did do it so that it would floating around). It's also a lot harder to find bugs when you're looking at your own code versus when someone sends you a crashdump because what they were doing is able to tickle a bug you'd never assume was possible. 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. We've also had working NFS lockd code in the BSD/OS tree on builder, along with full permission to grab it, for some time now but that hasn't made it happen because the right developers have yet to take that active an interest. Actually, that would do us well for the client side, however since we don't have anyone (so far) from BSD/os to explain the intracate parts of it, I'd rather see something come in that has someone familiar with the code rather than something we'd have to grok. Then again, I should take a look at the BSD/os rpc.lockd one weekend. David, you have builder access, what do you think about the BSD/os version? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
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 ? TfH -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rpc.lockd and true NFS locks?
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 delivering mail over NFS to FreeBSD homes? Procmail fcntl made our computing department especially unhappy, and we are wondering whether we can keep our migration strategy (moving our homes to backuped FreeBSD boxes). Some of the following quoted mails (consider this mail as a review, if you like) give hope that some people were working on this (without obviously having commited anything, as one can check in cvsweb). Is this true? Has anyone any server side patches for FreeBSD? Is he/she looking for guinea pigs? Anything is better than the current situation. Our users are running away from our otherwise very comfortable FreeBSD homes. :( On Mon, Apr 03, 2000 at 02:07:54PM +0200, Brad Knowles wrote: [...] Besides, file locking becomes impossible in -STABLE once you've mounted it with NFS (we don't have a working lockd, although work in this area is progressing in -CURRENT), and NFS writes generally suck when compared to local writes. [...] On Fri, Apr 07, 2000 at 08:07:40PM -0400, David E. Cross wrote: I apologize profusely for the delay of this, but lockd-0.2 is out. The URL is: http://www.cs.rpi.edu/~crossd/FreeBSD/lockd-0.2.tar.gz [...] 5) this does not add the code to FreeBSD's kernel to request the NFS locks (that is a job for people more skilled than I ;) [...] On Sat, Apr 08, 2000 at 12:23:14AM -0400, David E. Cross wrote: [...] http://www.cs.rpi.edu/~crossd/FreeBSD/lockd-0.2a.tar.gz [...] On Fri, Apr 07, 2000 at 08:44:33PM -0400, Andrew Gallatin wrote: This might be a bit touchy, but I'm rather curious -- how will the BSDI merger affect your lockd work? It seems like your work on lockd (esp. client side statd interoperation issues) could be speeded up if you had access to the BSDI sources.. On Tue, Sep 19, 2000 at 12:38:51PM +0200, Roman Shterenzon wrote: Quoting Andrew Gordon [EMAIL PROTECTED]: On Mon, 4 Sep 2000, Roman Shterenzon wrote: The rpc.lockd(8) is marked as broken in /etc/defaults/rc.conf in 4.1-R My question is - how bad is it broken? The rpc.lockd in 4.x simply answers "Yes" to all locking requests, and does not maintain any state. This means that if your programs actually need locking, running rpc.lockd will cause problems (file corruption etc). On the other hand, if your programs don't need locking and are just making the locking calls for the hell of it, rpc.lockd will allow these programs to run rather than just hanging up. There was talk a few months ago about someone having implemented NFS locking properly, but I haven't heard any more since - check the mailing list archives. [I wrote the existing 'hack' implementation]. On Wed, Sep 20, 2000 at 09:28:36AM -0500, Scot W. Hetzel wrote: From: "Roman Shterenzon" [EMAIL PROTECTED] On Tue, 19 Sep 2000 [EMAIL PROTECTED] wrote: [...] Someone (from something.edu, perhaps rpi.edu) posted a URL to one of the lists of a working but untested rpc.lockd. [...] I believe that Andrew means "David E. Cross" [EMAIL PROTECTED], but his citation some lines above show that he hadn't worked in that direction. I kind of remember reading about it on the current mailing list. Current-Users: Has a working rpc.lockd been imported into CURRENT. If it has, is there a possibility of getting it MFC'd to STABLE. On Thu, Sep 21, 2000 at 11:02:25AM +0930, Greg Lewis wrote: Look through the freebsd-hackers archive. There was an rpc.lockd implementation announced there looking for testers about a month or so before the 4.0 release. The person who wrote it is David Cross who is now a FreeBSD committer I believe. Thats my recollection anyway. Unfortunately I haven't seen any recent followups. At the time it was deemed too close to the 4.0 release. If you do test it maybe you can prod David with the results and get it committed to -current. On Wed, Nov 08, 2000 at 05:45:21PM +0100, Erik Trulsson wrote: On Wed, Nov 08, 2000 at 02:53:47PM +0100, cam wrote: I have to use rpc.lockd on my NFS server (FreeBSD 4.0-STABLE) and I've notice that it is broken with this line in /etc/defaults/rc.conf: 113: rpc_lockd_enable="NO" # Run NFS rpc.lockd (*broken!*) if nfs_server. You can't have looked that hard. This question did come up earlier this year on -questions and it wasn't difficult to find the answer searching through the list-archives. Anyway, the answer is that lockd is just a dummy implementation. When the client requests a lock rpc.lockd will just say "A lock? Sure, here you have one." without actually locking anything. The only reason for running this is when you have semi-broken clients (usually DOS/Windows based) that insist on getting
Re: rpc.lockd and true NFS locks?
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 through the librpc code). 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. 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. -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
* 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 little endian machines, but I have not yet had a chance to crawl through the librpc code). 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. 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 like to see it in both -current and -stable. Please take a deep breath and keep reading. :) I think that although it's partially broken if we gave appropriate warning to the users about the experimental nature of the code we'd be doing them a favor by getting the code out so that _early adopters_ so that they can give us feedback. I do not support removing the current "fake" lockd until we've had ironed out the issues with the experimental lockd. I do not like _only_ having it in -current because then people will never consider it, I have confidence that academic installations and hobbiests would give it a shot, and who knows, maybe we'll get a knock on the door from someone who's completed the client, after all, what use is the client code without the server code? As an interim solution we could put the lockd into the system as rpc.lockd-experimental. I think had we done this over six months ago when you made the initial announcement we'd have enough feedback to begin ironing out the kinks. I want this in the user's faces, taunting and enticing them to use it and give us feedback. :) So can you commit this? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
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 than the BSDI code. _However_ the BSDI code has undergone much more testing and design work than the rpics one. Given this I think the clear choice is with the BSDI code. sigh now, if I wasn't always getting buried with stuff. -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
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 Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
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 look at what our cousins have done and perhaps import it in -current ? according to http://mail-index.netbsd.org/cgi-bin/projects.cgi?token=mode=viewprojprojnum=70 code to do this was committed to netbsd on jun 7 2000. -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
: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 that the BSDI working lockd code was now available. On the otherhand I know that Dave and a lot of people spent a lot of hard work on lockd, and also on the kernel-side implementation. If we were to use the BSDI code the kernel-side implementation would almost certainly be retained with only minor (if any) modification. But the experiemental lockd code would be completely replaced. David, how do you feel about that potentially occuring? Would you like to make a go of it with the BSDI lockd code on builder? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
