My Favorites

Close

Please to see your favorites.

  • Bookmark
  • Email Document
  • Printer Friendly
  • Favorite
  • Rating:

SLES 9 NFS client sees duplicate files on NetApp Filer

This document (3992038) is provided subject to the disclaimer at the end of this document.

Environment

Novell SUSE Linux Enterprise Server 9 SP3

Situation

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.

Resolution

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).

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:3992038
  • Creation Date:21-NOV-06
  • Modified Date:27-APR-12
    • SUSESUSE Linux Enterprise Server

Did this document solve your problem? Provide Feedback

< Back to Support Search

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center