Date: Wed, 02 Mar 2005 16:24:02 -0500 From: Bob Johnson <bob89@eng.ufl.edu> To: freebsd-questions@freebsd.org Subject: FreeBSD NFS client and Netware 6.5 NFS server Message-ID: <42262EF2.8070503@eng.ufl.edu>
next in thread | raw e-mail | index | archive | help
Message below is about a FreeBSD server I maintain. The FreeBSD server is our web server. We use NFS to talk to a Netware file server where most of our users' web pages are stored. FreeBSD is 5.3, and was working ok with Netware 5.1 (and still is with other Netware servers). One of the servers was recently upgraded to Netware 6.5 and NFS is no longer playing nice between the two. When something on the Netware side updates a file by copying it into place (e.g. using FTP [don't complain] to upload a file), the FreeBSD client doesn't find out that the file contents have changed until it does something to the file (e.g. touch or chmod). Thus, when one of our users updates their web page with something like Dreamweaver, the web server doesn't find out about it (perhaps it eventually finds out, but it takes more than the several minutes we waited). As explained in the message below, a trace of the NFS server activity shows that the FreeBSD client implements ls -l as a series of <ACCESS> operations (whatever that is) followed by an <FS STAT>, while a Solaris client does a series of <GET ATTR> operations (those are the Netware abbreviations for the operations). The Solaris client does not exhibit any of these problems. I don't know if that is meaningful with regard to this problem, but clearly the Solaris client is doing things very differently than the FreeBSD client. Any (useful) suggestions about how to fix this? We've tried turning nfs_lockd and nfs_statd on and off on the client, we've tried both NFSv2 and NFSv3 (only v2 worked with the older Netware server), and a few other things that I don't remember. One of our other servers running FreeBSD 4.7 exhibits the same problem with Netware 6.5 NFS. Netware says they've tested their NFS server against FreeBSD 4.7 and that it works ok, so perhaps this should be treated as a Netware bug, but if anyone can suggest a quick way to make them play together it will be very much appreciated. Thanks, - Bob -------- Original Message -------- Subject: netware 6.5 nfs Date: Wed, 02 Mar 2005 15:51:31 -0500 From: Shawn To: Bob I've posted the following to a netware 6.5 support forum. ---------------------------------------------------------------------- POST #1 ---------------------------------------------------------------------- I just upgraded a netware 5.1 server to netware 6.5 overlay CD2 and am having problems with NFAU to a FreeBSD workstation. On a Windows workstation connected to the netware server with a drive mapping, if you edit files through the drive mapping (and subsequently save them directly to the volume) you immediately see the file changes at the FreeBSD mount point. However, if you edit and save the file on your local workstation and then copy the file over to the volume (the mapped drive), the FreeBSD system does not see the change in the file (I guess its NFS cache is not updating). If, on the FreeBSD system you touch (or chmod/chown) the file the cache gets updated and you see that the file has been updated. This was not a problem with NFAU under netware 5.1. Has anyone else seen this problem and/or have any possible things to look at tuning (I'm hoping someone has a cache setting to switch). (Am I even explaining this so it's understandable what's happening?) Before you ask, this is FreeBSD 5.3 (and I see that NFAU wasn't tested with this version)... I'm just holding out that there is something that can be done. ---------------------------------------------------------------------- POST #2 ---------------------------------------------------------------------- Here's some more information. Turns out it works just dandy if the volume gets mounted on a Solaris 8 workstation. I've done an NFS trace to see what is happening differently. The results of an 'ls' command on the Solaris workstation are: 100003.3.01 <GET ATTR> [TCP <SOLARIS-IP>] RStatus 0 Accept 0 NFS 0 And on the FreeBSD workstation the results are: 100003.3.04 <ACCESS> [TCP <FREEBSD-IP>] RStatus 0 Accept 0 NFS 0 100003.3.18 <FS STAT> [TCP <FREEBSD-IP>] RStatus 0 Accept 0 NFS 0 It has one 100003.3.01 or 100003.3.04 line for each file/dir in the directory where the 'ls' command happens... only one 100003.3.18 line per 'ls' command however. So the two NFS servers are doing something differently... just what and how to correct?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42262EF2.8070503>