Re: NFS Locking Issue



Michel Talon wrote:
I guess I'm still just a bit stunned that a bug this obvious not only found it's way into the STABLE branch, but is still there. Maybe it's not as obvious as I think, or not many folks are using it? All I know for sure here is that if I had upgraded to 6.1 my network would have been crippled.

Strange, since i upgraded to FreeBSD-6.1 and the NFS server to Fedora Core 5,
my machine, NFS client is happy, and lockd works. It is first time since
years i have no problem. It certainly did not work with FreeBSD-5 and i still
have a machine with FreeBSD-6.0 which does not work properly (frequently loses
the NFS mount, but it gets remounted some times later by amd). Anyways i have
exactly 0 problem with the 6.1 machine. I could extend that to say that
everything works very well on that machine, nothing is slow, including disk
access. This has not always been the case. Stability wise, i have not seen any
panic, hang or whatever since i have compiled a kernel adapted to my hardware.
I got a panic with the generic kernel soon after installation, but now
machine is totally stable.

Based on prior reading about this problem, I'd venture to guess that the file locking between FC5 and FreeBSD simply isn't. See, between just 2 machines sharing files without rpc.lockd running you won't see a problem. Both the client and the server must not only be running rpc.lockd, but they must be able to actually talk to each other.

For a simple 2 machine setup, you don't really need much in the way of locking control, as you don't have to deal with multiple requests for the same resource. This is why folks just running the "-L" flag on their mount command also aren't having any problems.

To actually see the problem isn't too hard to set up. Just have rpc.lockd, rpc.statd, and rpcbind enabled on both the client and the server. Then just starting trying to transfer a stack of files from one to the other. I found this to be true even trying to go from a 5.4 server to my 6.1 laptop here.

There was quite a thread on this back in March of this year, along with a few PR's that are still opened up. I'm personally just coming head long into all of this.

Later on,
--
Michael Collette
IT Manager
TestEquity Inc
Michael.Collette@xxxxxxxxxxxxxx
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: What is the futur of Native Code ?
    ... Having all your stuff on a online server limits maintainance ... There are a lot of folks who ... That leads to *distributed* applications (neither rich client nor web ...
    (borland.public.delphi.non-technical)
  • Re: cvsup server reachable via IPv6...
    ... you could use (with csup as the client obviously since cvsup doesn't do ... folks I got nudged into giving inetd/netcat a try as a means to feed ... IPv6 connections to the cvsupd server process. ...
    (freebsd-current)
  • Re: cvsup server reachable via IPv6...
    ... you could use (with csup as the client obviously since cvsup doesn't do ... folks I got nudged into giving inetd/netcat a try as a means to feed ... IPv6 connections to the cvsupd server process. ...
    (freebsd-stable)
  • Re: NFS Locking Issue
    ... I am not familiar with that, but I can tell you from experience that the nfs client code in 6.X has issues.. ... In particular if the server goes down the client machine doesn't allow you to unmount the volume.. ... found it's way into the STABLE branch, ...
    (freebsd-stable)
  • Re: Damn Blizzard
    ... Assuming you know how Blizzard spends the money they make does not equal ... Disconnects can equal 45 min queue. ... And it was due to scheduled server ... folks have like crashes and locked up machines are due to driver/OS issues. ...
    (alt.games.warcraft)