How does the volume language work on storage systems running Data ONTAP 7-mode?

Best practices:

• It is best if all volumes are of the same language. If a volume differs from the console language, commands with path names might not work.
• Do not change the language once it is set. 
  If the language must be changed, then do this before any file is created in the volume so that all file names use the same language. Changing the language after files are created in the volume can cause some NFS encodings to be invalid. The file names are then unreadable and cannot be found, making the files inaccessible. The best way to change a volume language is to create a new volume with the desired language set and use external software to copy the data in to the new volume. This will make sure the client creates the encodings as it expects and Data ONTAP will write it in a way to return exactly that to the client. 
• To see the same file names from Windows and UNIX, only use characters that are legal for both and are legal in the NFS character set.
  For example, do not put a Japanese file name on a French volume.
• Technically, there is no need to reboot after changing a volumes' language, since both the on-disk and the in-memory translation tables have been changed to the new language. But if error messages like Error starting OEM char set or Error starting NFS char set are encountered, then a reboot is required, since the new in-memory tables could not be built, perhaps due to insufficient memory. Besides, there is the risk of stale data in memory if the system is not rebooted.

Changing the volume language after data has been written might have some effects if it falls into any of the categories below:

1. If the volume contains only replicas of the Windows OSSV data, then there should be no cause for concern.
2. 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 might 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.

For NON-replica data:

1. If the volume's create_ucode and convert_ucode options are both OFF, and the NFS data is accessed only using NFS (NEVER by CIFS), there will be no issues.
2. If either create_ucode or convert_ucode option is set on the volume, or if the NFS data is accessed there could be some issues related to the NFS alternate name.
3. If you have files that have characters beyond 0x7f that are in non-Unicode directories you will have issues in accessing them after the switch. If you are sure that those do not exist, everything should be OK.

For files that are in Unicode directories that Unicode is definitive and the issue is that those names are translated based on the character set you specify. So, if the client is configured to accept UTF8 names, then everything should work.

Can I use an extended character set (i.e. Japanese) without changing the language on the storage system?

If the volume's language is a UTF-8 language set (i.e. en_US.UTF-8), and the client is writing filenames less than 255 bytes in length, the language does not need to change. If the filenames are quite long - e.g. longer than 85 characters, and each of the characters translates into 3-bytes of UTF-8, this will result in a filename larger than the allowed size and users would see the NFS alternative name if they attempted to access the file from NFS. In the above case, changing the language to a localized supported language (i.e. ja_v1) would allow 2 bytes per Japanese character, making the above 85 character file name only 170 bytes instead of 255. In this case, the administrator would still run into the file name limitation issue once you reach a file name of 128 characters.