FreeBSD NFS Mounts of NetWare shares do not update

FreeBSD NFS Mounts Do Not Update.

A FreeBSD mount of a NetWare file system exported through NFS do not show updated file date, time, nor size after file(s) change.

When FreeBSD has an NFS mount of the NetWare server, whether Traditional or NSS volume, and files on that NFS mount change, regardless of the method (NetWare Client, SMB, FTP, etc.,), the FreeBSD mount point does not reflect the change in file date, time, nor size.

LAN traces show that FreeBSD does not seem to be invaliding its cache and doing new lookups on the files. Most NFS Clients know to invalidate a directory cache when the parent directory's modification time stamp is updated. However, FreeBSD is not doing new lookups even after it sees this occur. Novell tests indicated that the FreeBSD NFS client requests new information about the contents of a directory when the directory's inode change date/time is updated. This time stamp is also known as ctime or attribute change time.

However, NetWare, not being a Unix file system, does not necessarily update the attribute change time stamp in the same cases that Unix does.

It is the NFS client's responsibility to decide when to invalidate it's cache and get new information, so this is fundamentally a FreeBSD issue. But there are potential solutions on both sides:

1. FreeBSD 6.1 seems to do a better job forcing the invalidation of it's cache on a timer than some older versions did. It also seems to use the acdirmax and acregmax settings effectively to control that timer. Using FreeBSD 6.1 and setting the acxxxmax settings to low values will solve this problem.

2. In NetWare 6.5 SP6, the NFS Server (XNFS.NLM) has been altered to help older versions of FreeBSD learn that they need to invalidate their cache. These changes are expected to insure that updated ctime stamps will be given to NFS clients in a wider variety of situations, which should solve this issue.

3. Aside from the above, workarounds when this situation occurs are:

a. Doing a 'touch' on the file(s) in question from FreeBSD will trigger it to lookup new information for that file upon the next directory listing. A cron job to periodically touch the file(s) may be of use.

b. Doing a 'touch' on the parent directory from FreeBSD (or any other client), which changes modification time, access time, and inode change time, triggering FreeBSD to look up new information. A CRON job to periodically touch the parent directory may be of use.

c. Deletion of the file(s) prior to replacement may also be of use, as these activities can parent directory time stamp updates.