SLES 9 NFS client sees duplicate files on NetApp Filer

  • 3992038
  • 21-Nov-2006
  • 27-Apr-2012


Novell SUSE Linux Enterprise Server 9 SP3


A system running SLES 9 SP3 is acting as an NFS client to a NetApp Filer. Occasionally, processes fail because the SLES NFS client believes there are duplicate files (2 files with the same name) in a single directory path on the NetApp filer.
This issue is connected with NFS client caching and the fact that NetApp filers may make significant changes to a directory without updating the modification time (mtime). NFS clients typically use mtime to determine whether the client cache needs to be flushed. This time checking is even done with the NFS client uses the noac option.
The specific scenario with the NetApp file and NFS client cache is believed to be as follows:
Certain options for a NetApp volume control how UNICODE entries are created on the filer. These two volume options are "create_ucode" and "convert_ucode". Assume these options are set "off" on a multi-protocol volume (i.e. NFS access plus CIFS access, maybe other methods as well), and then a UNIX/NFS client creates a directory tree with lots of files. Since NFS doesn't care about UNICODE, the directory doesn't yet contain the UNICODE entries which CIFS would need for access.
Later, a CIFS client accesses this directory tree, so the filer performs a "directory conversion" which creates the necessary UNICODE on the fly. This conversion process can cause a reorganization of the directory and can result in a situation where the same directory entries which were initially fetched with one cookie later appear with another cookie value. Meanwhile, the only time stamp that changed in relation to the creation of UNICODE names was the NFS "inode change time," also known as ctime. This refers to a meta-data change but is not supposed to be taken as a content change, and therefore the client cache is not flushed.
Potentially, the NetApp filer should be updating the modification time (mtime) as well, or changing the cookie verifier; but it is not. Therefore a typical NFS client might encounter a situation where it attempts to get some new information to supplement the information it already has in cache, and receives results that appear contradictory, and which give the impression of additional files with names matching already-known files.


Both the above-mentioned UNICODE options on the NetApp filer should be set to "on". The behavior which can be expected from this is as follows:
"create_ucode = on" - With this on, any new entries created by NFS clients will contain UNICODE for CIFS accesses.
"convert_ucode" = on" - With this on, any NFS client access of already-existing non-UNICODE entries will result in a directory conversion, so it won't just be CIFS access that triggers conversion.
Once both of these options were turned on, the problematic scenario will no longer be created, although it can take time for existing entries without UNICODE to all be converted, and thus relieve all symptoms.
To force all entries to be accessed and converted right away, after turning these options on, go to an NFS client and freshly mount the file system. If it was already mounted, umount and mount again. Then cd into the mount point and do ls -alR (which will do a directory listing of the entire mounted file system, and could take considerable time). This, in theory, should trigger conversion for all entries that need it. (NOTE: this theory is based on information provided by NetApp, not verified through Novell testing).

Feedback service temporarily unavailable. For content questions or problems, please contact Support.