Skip to main content

NetApp_Insight_2020.png 

NetApp Knowledgebase

Implications of changing the language of a volume after data has been written to it?

Views:
200
Visibility:
Public
Votes:
1
Category:
data-ontap-8
Specialty:
core
Last Updated:

Applies to

Data ONTAP 7 and earlier

Answer

  • Every volume has a language.
    The language of the volume determines the character set Data ONTAP uses to display file names and data for that volume.
    This language setting affects only the file names and does not affect data within the files 
     
  • The volume language is used to translate incoming NFSv3 names to Unicode.
    The volume language is also used to translate existing Unicode directory names to an NFS encoding before returning the names from NFS READDIR operation.
     
  • So it is always recommended to set the the volume language before writing data into the volume.
    However, there might be situations where there is a need to change the volume language after the data has been written.
    In order to understand the implications of changing the volume language after the data has been written, we need to to see how the data was created.
     
  • If the files were created by Windows CIFS clients, then they are stored in the directory in Unicode.
    Display of the filename and access from Windows CIFS will use Unicode and the non-ascii characters are visible to Windows.
    But for NFSv3, only characters in the unicode range will be translatable and visible to nfs clients.
    Other characters will not translate, so the file will be seen and accessed from NFS by its NFS alternate name. 
    NFSv4 is not a problem as it requires the use of UTF-8.
     
  • If you change the volume language to UTF-8, any existing Unicode names can always be translated to UTF-8, so a properly encoded NFSv3 clients expecting UTF-8 should be able to operate on such names reliably.
    Those names will also look correct when seen by Windows clients, since CIFS always expects Unicode names.
     
  • If the files were created by NFSv3 and the filename contained invalid characters, the filename will be stored as the exact bytes that were provided.
    This is because those characters cannot be converted to unicode and this may happen when the name is encoded incorrectly by the client.
     
  • In such cases, no translation is done and NFSv3 will see the file and access it by the exact same bytes that were given when it was created.
    Since it does not translate to unicode, Windows will only see the 8.3 name for the file.
     
  • If the language is changed to UTF-8 and those bytes happen to be valid UTF-8, an access to the file will translate the UTF-8 to Unicode and try to find a file with that Unicode name.
        If one does exist, that will be the file accessed, which is not the intended file.
        If one doesn't exist, there will be an error, even though the directory read showed such a file.
     
  • In such scenarios, the the correct names could be recovered for use by CIFS if an NFS client configured for UTF-8 copy or rename the files to a volume with UTF-8 encoding.
    That resolves the issue because the encoding sent by the client would match the volume language.
     

Volume language change and replication implications

  • If the volume contains only replicas of the Windows OSSV data, then there should be no cause for concern.
  • If ALL of the following conditions prevail, then there is no workaround except re-initializing the SnapVault or qtree SnapMirror relationships when they fail
  1. The volume contains replica qtrees of non-unicode sources, that is:
    • Storage system qtrees which were not accessed by Common Internet File System (CIFS) protocol and where the volume options create_ucode and convert_ucode are both OFF.
    •  Non-Windows OSSV primary data.
  2.         The volume has create_ucode turned on, and the secondary is not.
  3.         The primary data has non-ASCII filenames with multiple hardlinks in the same directory (not same directory tree, but same directory).
  • For replica data not falling into either of the above categories:
    • NFS access on the secondary volume might be impaired (names look odd, or you can only see an NFS alternate name like :8U10000) until a directory operation happens on the primary, and a successful update operation completes.
    • To accelerate recovery in this case, rename each non-ASCII filename on the primary.Ideally, you would rename each to another directory, and then rename it to its original position. Then snapvault/snapmirror update correctly.

Additional Information

additionalInformation_text