Date: Thu, 3 Mar 2005 11:05:43 -0600 From: Dan Nelson <dnelson@allantgroup.com> To: Shawn C Lander <shawn@eng.ufl.edu> Cc: bob@eng.ufl.edu Subject: Re: FreeBSD NFS client and Netware 6.5 NFS server] Message-ID: <20050303170543.GA85412@dan.emsphone.com> In-Reply-To: <1D52879BC0ECB86DD544A61D@mis-shawn-160> References: <42262EF2.8070503@eng.ufl.edu> <20050302235524.GE77052@dan.emsphone.com> <42267088.402@eng.ufl.edu> <1D52879BC0ECB86DD544A61D@mis-shawn-160>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <dnelson@allantgroup.com>
> >To: Bob Johnson <bob89@eng.ufl.edu>
> >CC: freebsd-questions@freebsd.org
> >References: <42262EF2.8070503@eng.ufl.edu>
> >
> >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
dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050303170543.GA85412>