In the last episode (Mar 03), Shawn C Lander said: > An NFS trace on the novell server shows the web server executing > GETATTR and READ commands when a file is served after it has been > updated.
If it's doing a GETATTR and a READ, then it should be pulling the right file data, I think. Can you get the contents of the READ reply, and see whether the Netware box is sending old or new file contents? > If you 'touch' one of the files, the client executes GETATTR and > SETATTR... and then the first time it is served it executes LOOKUP, > READ, and GETATTR commands (after the first time it is served by the > web server the client just executes GETATTR and READ). I wonder if it's the lookup result (i.e. name->filehandle mapping) that's being incorrectly cached, instead of the attributes (i.e. filehandle timestamp etc). If the webpage upload creates a new file instead of updating the existing one, the FreeBSD client may be caching the filehandle from the previous lookup call and fetching the old file (which Netware still has a copy of because of the NWFS/NSS salvage system). If this were the case, though, I would expect to see your Solaris box do LOOKUPs occasionally to verify that its cached filehandle is still good. > We were told to mount the exported volume with the NOAC option to > tell the client not to cache file attributes. However, we do not see > this option implemented on FreeBSD (we even tried it thinking it may > be undocumented or still hanging around and ended up getting an error > message). After seeing this, we tried setting ACREGMIN, ACREGMAX, > ACDIRMIN, and ACDIRMAX to 0 thinking that timeouts of 0 would > essentionally turn the cache off... but it didn't solve the problem. > Is there some other setting that just turns the cache off completely? That should have done it, I think. Looking around /sys/nfsclient/nfs_subs.c I see there is an NFS_ACDEBUG kernel option you could enable which creates a vfs.nfs.acdebug flag. If you set it to 3, the kernel should print out some timing info every time it fetches an attribute from its cache. I don't know the relationship between vfs.nfs.access_cache_timeout and the ag{reg,dir}{min,max} mount_nfs flags. > >-------- Original Message -------- > >Subject: Re: FreeBSD NFS client and Netware 6.5 NFS server > >Date: Wed, 2 Mar 2005 17:55:24 -0600 > >From: Dan Nelson <[EMAIL PROTECTED]> > >To: Bob Johnson <[EMAIL PROTECTED]> > >CC: freebsd-questions@freebsd.org > >References: <[EMAIL PROTECTED]> > > > >In the last episode (Mar 02), Bob Johnson said: > >>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). > > > >It sounds sort of like the vfs.nfs.access_cache_timeout sysctl isn't > >being honored on the FreeBSD side. The kernel defaults to 60 seconds, > >but if you have nfs_client_enable="YES" in rc.conf, /etc/rc.d/nfsclient > >sets it to 2. If you dump the NFS traffic as your web server fetches > >one of these recently-updated files, do you see it doing an > >ACCESS/GETATTR on the target files at all? -- Dan Nelson [EMAIL PROTECTED] _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"