This last week I had been working on a test network to test out 6.1 prior to upgrading our production boxes from 5.4. That's when I ran across the rpc.lockd issues that have been discussed earlier. Our production setup has diskless clients running KDE, which due to this bug is now dead on 6.1. I also have my mail server delivering messages to a file server via NFS. I even have servers booting diskless with NFS provided file systems... all of which are dead on 6.1. The last discussion our bug updates I've seen on this issue were about 3 months ago. This leaves me with a number of questions I hope can be answered here on this list. Is NFS a big deal for most other users, or am I out here on the fringe using it as much as I do? Is anyone working on a fix for this? If so, is there any kind of time frame where this fix might be MFC'd to 6-STABLE? 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. Later on, -- Michael Collette IT Manager TestEquity LLC Michael.Collette@TestEquity.com
me - too ... 2006/6/29, Michael Collette <Michael.Collette@testequity.com>:> > This last week I had been working on a test network to test out 6.1 > prior to upgrading our production boxes from 5.4. That's when I ran > across the rpc.lockd issues that have been discussed earlier. > > Our production setup has diskless clients running KDE, which due to this > bug is now dead on 6.1. I also have my mail server delivering messages > to a file server via NFS. I even have servers booting diskless with NFS > provided file systems... all of which are dead on 6.1. > > The last discussion our bug updates I've seen on this issue were about 3 > months ago. This leaves me with a number of questions I hope can be > answered here on this list. > > Is NFS a big deal for most other users, or am I out here on the fringe > using it as much as I do? > > Is anyone working on a fix for this? If so, is there any kind of time > frame where this fix might be MFC'd to 6-STABLE? > > 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. > > Later on, > -- > Michael Collette > IT Manager > TestEquity LLC > Michael.Collette@TestEquity.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >-- ? ?????????, ??????? ?????????. ??????????????, ??????????, ????????????????? ? ????????? ?????????????? ??????.
Michael Collette writes:> This last week I had been working on a test network to test out 6.1 > prior to upgrading our production boxes from 5.4.I wish I had done that.. :-(> That's when I ran > across the rpc.lockd issues that have been discussed earlier.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.. and if you have programs trying to acces the downed mount, the whole machine may end up freezing.>... I also have my mail server delivering messages > to a file server via NFS.We use NFS as our "storage" sever for pop/imap, but use the MTA to deliver to the machine.> Is NFS a big deal for most other users, or am I out here on the fringe > using it as much as I do?It is for us.. I am even trying to see if we can even pay someone to expedite getting NFS fixed in 6. Unfortunately we decided to increase our NFS usage after I had installed 6.X in a number of new machines.> Is anyone working on a fix for this?If there is I have not read about it.> 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.I am fairly new to NFS.. but I am getting the impression that FreeBSD's NFS is not as mature as other platforms. I also think it has a lot to do with usage patterns. I have seen mentions of people having hundreds of clients connected to a single NFS server... yet I see problems with just a handfull of clients. Maybe the issue is only with the 6.X branch. Sadly part of the reason I moved some newer machines to 6.X was because of some comments I saw on how NFS had been improved in 6.X :-(
Rong-en Fan wrote:> On 6/29/06, Michael Collette <Michael.Collette@testequity.com> wrote: >> This last week I had been working on a test network to test out 6.1 >> prior to upgrading our production boxes from 5.4. That's when I ran >> across the rpc.lockd issues that have been discussed earlier. >> >> Our production setup has diskless clients running KDE, which due to this >> bug is now dead on 6.1. I also have my mail server delivering messages >> to a file server via NFS. I even have servers booting diskless with NFS >> provided file systems... all of which are dead on 6.1. >> >> The last discussion our bug updates I've seen on this issue were about 3 >> months ago. This leaves me with a number of questions I hope can be >> answered here on this list. >> >> Is NFS a big deal for most other users, or am I out here on the fringe >> using it as much as I do? >> >> Is anyone working on a fix for this? If so, is there any kind of time >> frame where this fix might be MFC'd to 6-STABLE? >> >> 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. > > Try 6.1-STABLE, especially make sure you have > > $FreeBSD: src/usr.sbin/rpc.lockd/kern.c,v 1.16.2.1 2006/06/02 > 01:20:58 rodrigc Exp $ > > for usr.sbin/rpc.lockd/kern.c, and see if this helps.I am running STABLE on all my test boxes, and the problem is very much there. It's not everything that locks up though. I'm able to bring X up with twm, but unable to launch any Gnome or KDE applications without them being stranded in a lock state. I sure would have loved for your suggestion to be correct. For what it's worth, all the boxes I'm working with are on STABLE no more than a week old. I ran fresh build worlds on all of them before getting the rest of my configs going. Thanks, -- Michael Collette IT Manager TestEquity LLC Michael.Collette@TestEquity.com
> 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. -- Michel TALON
Michel Talon writes:> 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.What volume are we talking about? My own problems and other reports I see are all under heavy load.
On Thu, 29 Jun 2006, Francisco Reyes wrote:> Michel Talon writes: > >> 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. > > What volume are we talking about? > My own problems and other reports I see are all under heavy load.the one thing that sticks out to me about this report is that they upgraded teh NFS server to FC5 ... what was the server running before? if FreeBSD, could the problem be an interaction problem between the NFS server and client, vs just the client side? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
User Freebsd writes:> the one thing that sticks out to me about this report is that they > upgraded teh NFS server to FC5I wonder if the FreeBSD 6.X client would freeze with a non FreeBSD NFS server. Would be interesting to have that info for comparison.
> the one thing that sticks out to me about this report is that they > upgraded teh NFS server to FC5 ... what was the server running before? if > FreeBSD, could the problem be an interaction problem between the NFS > server and client, vs just the client side?Previously the server used Fedora Core 3. I think like you that it is an interaction between client and server. For example we have a client machine running Debian Unstable which had NFS problems interacting FC3 server and still has with FC5 server. But i don't have any more with Fbsd-6.1. As to the problem of the machine freezing when the server freezes i have always seen that, both under Linux and FreeBSD, nothing new. The freeze seems to me less severe now, that is i have been able to log in root with the server down. The load on the server is rather big, we are talking around 100 machines having their home directories on the server. -- Michel TALON
> I only started to see the lockd problems when upgrading the server side > to FreeBSD 6.x and later. I had various FreeBSD clients, between 4.x > and 7-current and the lockd problem only showed up when upgrading the > server from 5.x to 6.x.As far as i remember FreeBSD-4 did not have a true lockd, only a fake one, so it was always working no problem. I have used all versions of FreeBSD-5 up to 6.0 and 6.1 on my client with a Linux server, and i can say that 6.1 is the first one which works OK for me. I don't have any experience with FreeBSD server, except the occasional nfs mounting after a make world. -- Michel TALON
> 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. >I definitely disagree with that. I have written a little program just to check locking on files on the NFS share, and i can assure you it works. Before FC5 the same program did not work, in fact hanged. You could not kill the program, without unmounting the NFS share. After the upgrade FC3 -> FC5 the lockd works and if i try setting a second lock on the same file it will fail. I am using this daily with mutt, no problem. But it is not only lockd which now works, it is more generally NFS. On a 6.0 machine i regularly get things like: Jun 22 17:30:10 asmodee kernel: for server ada:/ada1 Jun 22 17:30:10 asmodee kernel: nfs send error 1 for server ada:/ada1 Jun 22 17:30:10 asmodee last message repeated 797 times Jun 22 17:30:15 asmodee kernel: for server ada:/ada Jun 22 17:30:15 asmodee kernel: nfs send error 1 for server ada:/ada Jun 22 17:30:15 asmodee last message repeated 817 times Jun 22 17:30:20 asmodee kernel: nfs send error 35 for server ada:/ada and the home directories are inaccessible for a couple of minutes. I have never seen that once on the 6.1 machine. -- Michel TALON
On 6/29/06, Michael Collette <Michael.Collette@testequity.com> wrote:> This last week I had been working on a test network to test out 6.1 > prior to upgrading our production boxes from 5.4. That's when I ran > across the rpc.lockd issues that have been discussed earlier. > > Our production setup has diskless clients running KDE, which due to this > bug is now dead on 6.1. I also have my mail server delivering messages > to a file server via NFS. I even have servers booting diskless with NFS > provided file systems... all of which are dead on 6.1. > > The last discussion our bug updates I've seen on this issue were about 3 > months ago. This leaves me with a number of questions I hope can be > answered here on this list. > > Is NFS a big deal for most other users, or am I out here on the fringe > using it as much as I do? > > Is anyone working on a fix for this? If so, is there any kind of time > frame where this fix might be MFC'd to 6-STABLE? > > 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.Try 6.1-STABLE, especially make sure you have $FreeBSD: src/usr.sbin/rpc.lockd/kern.c,v 1.16.2.1 2006/06/02 01:20:58 rodrigc Exp $ for usr.sbin/rpc.lockd/kern.c, and see if this helps. Regards, Rong-En Fan
Kostik Belousov writes:> I think that then 6.2 and 6.3 is not for you either. Problems > cannot be fixed until enough information is given.I am trying.. but so far only other users who are having the same problem are commenting on this and other simmilar threads. We just need some guidance.. Mark gave me a URL to turn on debugging and volunteered ot give me some pointers.. I will try, but I will likely try on my own time, on my own machines.. I can not tell the owner of the company I work for to let me "try".. or "play around" in production machines.. as we loose customers because of current problems with the 6.X line.> Since nobody except you experience that problems (at least, only you notified > about the problem existence)Did you miss the part of:> User Freebsd writes: >>Since there are several of us experiencing what looks to be the same sort >>of deadlock issue, I beseech you not to give upI am not the only one reporting or having the issue.> Is this for intr mounts?"intr" ?> improved handling of signals in nfs client. If you could test it, that > would be useful.Does it matter if the OS is i386 or am64? Have an amd64 machine I can more easily play with... with no risk to production.
On Mon, Jul 03, 2006 at 12:50:11AM -0400, Francisco Reyes wrote:> Kostik Belousov writes: > >Since nobody except you experience that problems (at least, only you > >notified > >about the problem existence) > > Did you miss the part of: > > >User Freebsd writes: > >>Since there are several of us experiencing what looks to be the same sort > >>of deadlock issue, I beseech you not to give up > > I am not the only one reporting or having the issue.I think you have different issues.> > >Is this for intr mounts? > > "intr" ?Mount option that allows to interrupt nfs operation by signal. See mount_nfs(8). BTW, I had the impression that this feature not working was one of your problem.> > > >improved handling of signals in nfs client. If you could test it, that > >would be useful. > > Does it matter if the OS is i386 or am64? > Have an amd64 machine I can more easily play with... with no risk to > production.No, this shall be applicable to any arch. Except that the patches are several month old, and were developed against CURRENT. But I think that it is applicable to STABLE. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060703/52b7126d/attachment.pgp
Quoting Michel Talon <talon@lpthe.jussieu.fr>:>> 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.So it would appear that you cured the NFS problems inherent with FBSD-6 by replacing FBSD with Fedora Linux. Nice to know that NFSd works in Linux. But won't help those on the FBSD list fix their FBSD-6 boxen. :/> > > > -- > > Michel TALON > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >-- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: PGP Digital Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060703/06da0fb0/attachment.pgp
On Mon, 3 Jul 2006, Kostik Belousov wrote:> On Mon, Jul 03, 2006 at 12:50:11AM -0400, Francisco Reyes wrote: >> Kostik Belousov writes: >>> Since nobody except you experience that problems (at least, only you >>> notified >>> about the problem existence) >> >> Did you miss the part of: >> >>> User Freebsd writes: >>>> Since there are several of us experiencing what looks to be the same sort >>>> of deadlock issue, I beseech you not to give up >> >> I am not the only one reporting or having the issue. > I think you have different issues.I agree. It looks like we have several issues floating around. There are some known issues with rpc.lockd (and probably some unknown ones) that will require a concerted effort to resolve. There appear to be a number of reports relating to this/these problems. It sounds like there is also an NFS client race condition or other bug of some sort. I think it would be really useful to isolate the two during debugging. Specifically, to make sure that the second client bug is reproduceable without rpc.lockd running on the client (and related mount flags). Once we have some more information, such as vnode locking information, client thread stack traces, etc, we should probably get Mohan in the loop if things seem sticky. I believe he was on vacation last week; he may be back this week sometime. With the July 4 weekend afoot, a lot of .us developers are offline. Robert N M Watson Computer Laboratory University of Cambridge
On Mon, Jul 03, 2006 at 10:06:52AM +0100, Robert Watson wrote:> > On Mon, 3 Jul 2006, Kostik Belousov wrote: > > >On Mon, Jul 03, 2006 at 12:50:11AM -0400, Francisco Reyes wrote: > >>Kostik Belousov writes: > >>>Since nobody except you experience that problems (at least, only you > >>>notified > >>>about the problem existence) > >> > >>Did you miss the part of: > >> > >>>User Freebsd writes: > >>>>Since there are several of us experiencing what looks to be the same > >>>>sort > >>>>of deadlock issue, I beseech you not to give up > >> > >>I am not the only one reporting or having the issue. > >I think you have different issues. > > I agree. It looks like we have several issues floating around. There are > some known issues with rpc.lockd (and probably some unknown ones) that will > require a concerted effort to resolve. There appear to be a number of > reports relating to this/these problems. > > It sounds like there is also an NFS client race condition or other bug of > some sort. > > I think it would be really useful to isolate the two during debugging. > Specifically, to make sure that the second client bug is reproduceable > without rpc.lockd running on the client (and related mount flags). Once we > have some more information, such as vnode locking information, client > thread stack traces, etc, we should probably get Mohan in the loop if > things seem sticky. I believe he was on vacation last week; he may be back > this week sometime. With the July 4 weekend afoot, a lot of .us developers > are offline.I too did noted some time ago that unresposible nfs server takes nfs client down. I then looked at the issue, and have the impression that this is again the case of runningbufspace depletion. I got a lot of processes in wdrain and flswai states. After nfs server repaired, active write requests were executed, number of dirty buffers decreased, and system returned to normal operation. This seems to be an architectural issue. I tried to bring discussion up several month ago, but got no response. And, there is the small problem about SIGINT being ignored when mounted with intr flag. Patch to fix this is attached in my previous mail. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060703/b48db07f/attachment.pgp
On Mon, Jul 03, 2006 at 10:06:52AM +0100, Robert Watson wrote:> It sounds like there is also an NFS client race condition or other bug of > some sort.It may not be related, directly, but one thing that I noticed, while trying to sort out my own recently commissioned NFS setup, is that the -r1024 mount flag is *crucial* when the network is 100BaseT and the server is a new, fast amd64 box, and the client is an old P3-500 with a RealTek ethernet card. It works fine, now, but tcpdump showed that it was retrying forever without. Even NFS over TCP seemed to suffer a bunch of error-related retries which amounted to stalls in the client. Is there any way for this sort of thing to be adjusted automatically? Cheers, -- Andrew
> So it would appear that you cured the NFS problems inherent with FBSD-6 > by replacing FBSD with Fedora Linux. Nice to know that NFSd works in Linux. > But won't help those on the FBSD list fix their FBSD-6 boxen. :/ >First NFS is designed to make machines of different OSs interact properly. If a FreeBSD server interacts properly with a FreeBSD client, but not other clients, you cannot say that the situation is fine. Second i am not the one to chose the NFS server, there are people working in social groups, in the real world. And third, the most important, the OP message seemed to imply that the FreeBSD-6 NFS client was at fault, i pointed out that in my experience my FreeBSD-6.1 client works OK, while the 6.0 doesn't, when interacting with a FC5 server. This is in itself a relevant piece of information for the problem at hand. It may be that the server side is at fault, or some complex interaction between client and server. Anyways some people claimed here that they had no problem with FreeBSD-5 clients and servers. My experience is that i had constant problems between FreeBSD-5 clients and Fedora Core 3 servers. I cannot provide any other data point. I am not particularly sure of the quality of the FC3 or FC5 NFS server implementation, except that the ~ 100 workstations running the similar Fedora distribution work like a charm with their homes NFS mounted on the server. On the other hand a Debian client machine also has severe NFS problems. My only conclusion is that these NFS stories are very tricky. The only moment everything worked fine was when we were running Solaris on the server. -- Michel TALON
> Using Ubuntu as the server I connected a FreeBSD 5.4 and 6-stable box as > clients on a 100Mb/s network. The time trial used a dummy 100Meg file > transfered from the server to the client. >I have similar experiences here. With FreeBSD-6.1 as client (using an Intel etherexpress card at 100 Mb/s) and FC5 server i see full wire speed for file transfers via NFS.> After the 4th of July I intend to test Ubuntu as a client to a FreeBSD > 6-STABLE server on a gigabit lan to run similar time trials. I'm > looking to confirm what I can only suspect at this point, which is that > the NFS server on FreeBSD is mucked up, but the client is okay.I have the same impression. The 6.1-RELEASE client seems to work well. Yesterday i have upgraded my 6.0 (*) box to 6.1 and i have not seen a single NFS problem after that. Moreover i am using rpc.statd, and rpc.lockd and they work OK and are really functional. I have the following sysctl which may have an effect on the problem: vfs.nfs.access_cache_timeout=5 So it may well be that it is the FreeBSD NFS server code which has problems. (*) 6.0-RELEASE client definitively does not work OK for me. -- Michel TALON
> BTW, I noticed yesterday that that IPv6 support committ to rpc.lockd was never > backed out. An immediate question for people experiencing new rpc.lockd > problems with 6.x should be whether or not backing out that change helps.So it may be relevant to say that i have kernels without IPV6 support. Recall that i have absolutely no problem with the client in FreeBSD-6.1. Tomorrow i will test one of the 6.1 machines as a NFS server and the other as a client, and will make you know if i see something. As to the problems you mention about NFS Linux, yes i have seen a lot since years. But to my surprise FC5 seems to work well. By the way it is kernel 2.6.16 so sufficiently recent for the problems to have been ironed out, presumably. -- Michel TALON
> Michel Talon wrote: > > >>Using Ubuntu as the server I connected a FreeBSD 5.4 and 6-stable box as > >>clients on a 100Mb/s network. The time trial used a dummy 100Meg file > >>transfered from the server to the client. > >> > > > > > > I have similar experiences here. With FreeBSD-6.1 as client (using an Intel > > etherexpress card at 100 Mb/s) and FC5 server i see full wire speed for file > > transfers via NFS. > > > > > >>After the 4th of July I intend to test Ubuntu as a client to a FreeBSD > >>6-STABLE server on a gigabit lan to run similar time trials. I'm > >>looking to confirm what I can only suspect at this point, which is that > >>the NFS server on FreeBSD is mucked up, but the client is okay. > > > > > > I have the same impression. The 6.1-RELEASE client seems to work well. > > Yesterday i have upgraded my 6.0 (*) box to 6.1 and i have not seen a single > > NFS problem after that. Moreover i am using rpc.statd, and rpc.lockd > > and they work OK and are really functional. > > I have the following sysctl which may have an effect on the problem: > > vfs.nfs.access_cache_timeout=5 > > > > So it may well be that it is the FreeBSD NFS server code which has problems. > > > > (*) 6.0-RELEASE client definitively does not work OK for me. > > > > > > For what it's worth, I recently spent a lot of time putting FreeBSD 6.1 > to the test as both an NFS client and server in a mixed OS environment. > By far and away, the biggest problems that I encountered with it were > due to linux NFS bugs. CentOS, FC, and SuSE all created huge problems > under load, and it was impossible to get stable results until I started > using 2.6.12 and higher kernels. > > I have a variety of theories that I wish I had had time to test. I've > seen hints of problems with READDIRPLUS, with FreeBSD's habit of mapping > GETATTR to ACCESS, and with handle sizes. But in any case, it's been no > secret that Linux has had very severe NFS problems in the past, and that > the NetApp folks have worked very hard over the last year to fix them in > the most recent Linux kernel releases. The only real fault I give > FreeBSD is rpc.lockd. It's pretty much useless in all but trivial > circumstances. Beyond that, make sure you're using a linux kernel that > is relatively recent. >In my case our main servers are NetApp, and the problems are more related to am-utils running into some race condition (need more time to debug this :-) the other problem is related to throughput, freebsd is slower than linux, and while freebsd/nfs/tcp is faster on Freebsd than udp, on linux it's the same. So it seems some tunning is needed. our main problem now is samba/rpc.lockd, we are stuck with a server running FreeBSD 5.4 which crashes, and we can't upgrade to 6.1 because lockd doesn't work. So, if someone is willing to look into the lockd issue, we would like to help. danny> Scott > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
> So it may be relevant to say that i have kernels without IPV6 support. > Recall that i have absolutely no problem with the client in FreeBSD-6.1. > Tomorrow i will test one of the 6.1 machines as a NFS server and the other as > a client, and will make you know if i see something.Well, i have checked between 2 FreeBSD-6.1-RELEASE machines on the network, both have fxp ethernet driver running at 100 Mb/s, one is NFS server other NFS client. Both run lockd and statd. I have absolutely no problem exchanging files, for example if i begin to copy /usr/src through NFS from one machine to the other, which makes a lot of transactions of all sorts, i get: niobe# mount asmodee:/usr/src /mnt cp -R /mnt/src . ... after some time i interrupt the transfer niobe% du -sh . 131M . and during this time i observe the following type of statistics asmodee% netstat -w 1 -I fxp0 input (fxp0) output packets errs bytes packets errs bytes colls 542 0 84116 1330 0 1219388 0 515 0 72806 1290 0 1196330 0 501 0 95722 1081 0 741048 0 539 0 90704 1090 0 1228052 0 645 0 67888 902 0 1451098 0 405 0 81264 1609 0 604278 0 503 0 74218 709 0 924422 0 500 0 98904 973 0 619350 0 550 0 100122 855 0 836328 0 615 0 79336 1081 0 862772 0 577 0 82862 901 0 1005024 0 which looks decent to me. Doing the same with just one big file no problem either, and i get a transfer speed of 6.60 MB/s which is perhaps a little less than with linux, but nothing catastrophic. I get 8.20 MB/s for FreeBSD client interacting with the Linux server. Now netstat gives packets errs bytes packets errs bytes colls 785 0 123266 4716 0 6825600 0 759 0 139898 4530 0 7747276 0 852 0 124652 5106 0 6902566 0 863 0 128040 5170 0 7081738 0 811 0 123760 4862 0 6851498 0 789 0 123540 4720 0 6834310 0 840 0 115378 5024 0 6382114 0 So up to what i can see NFS works OK for me on FreeBSD-6.1. So the main difference with other people cases may be that i have removed IPV6 support from kernel. -- Michel TALON
> with the bge driver ... could we be possibly talking internet vs nfs > issues?Pursuing invetigations, i have discovered that for people having workstations whose home directories are on a NFS server, and who run Gnome or KDE, there is a program which has horrible NFS behavior, it is gam_server from gamin, which detects alterations on your .kde for example. On my machine running nfsstat -c -w 1 i see 4000 requests/s due to that. If i displace it (*) and kill it, this drops to 80 requests/s and KDE works exactly as well, including discovering new files. I think it is not necessary to comment on the performance penalty if a number of stations send 4000r/s to a server, it will soon be killed. (*) it restarts itself automatically so it is necessary to displace or rename it before killing. -- Michel TALON