How does the volume language work on storage systems running Data ONTAP 7-mode?
Applies to
Data ONTAP 7-mode
Answer
Check Active IQ if this impacts your systems
Every volume has a language. The storage system uses a character set appropriate to the language. The language of a volume can be specified during volume creation or can be modified later after creation. By default, the language of a volume is the same as that of the root volume. In some cases, volume language is not required to be set. The following are the different situations:
- If the volume is used for NFS ( less than V4) only:
Do nothing ( but, it does matter when the files are created by Unicode clients) - If the volume is used for CIFS only or NFSv4 and later:
Volume language is not relevent for CIFS. For NFS set the language of the volume to the language of its clients. - If the volume is used for both CIFS and NFS (less than V4)
Set the language of the volume to the locale used by NFS. - Activate these options immediately on volume creation by turning on create_ucode and convert_ucode volume options.
vol options <volume_name> create_ucode on | off
vol options <volume_name> convert_ucode on | off - Downlevel legacy clients such as MSDOS, which do not support unicode. Do require the volume language setting - this provides the OEM character set used by these clients.
For legacy clients, use the 'en' volume language setting which provides the normal NFS character set and cp850 OEM character set which covers most European countries including German, Spanish, and French. Otherwise, use 'en_US' which provides the NFS character set and the cp437 OEM character set. The differences between these two can be found in the relevantcp850.h
andcp437.h
header files.
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
orError 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:
- 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:
- 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
andconvert_ucode
are both OFF - Non-Windows OSSV primary data
- Storage system qtrees which were not accessed by Common Internet File System (CIFS) protocol and where the volume options
- The volume has
create_ucode
turned on, and the secondary is not. - The primary data has non-ASCII filenames with multiple hardlinks in the same directory (not same directory tree, but same directory)
- The volume contains replica qtrees of non-unicode sources, that is,
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:
- If the volume's
create_ucode
andconvert_ucode
options are both OFF, and the NFS data is accessed only using NFS (NEVER by CIFS), there will be no issues. - If either
create_ucode
orconvert_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. - 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.
Additional Information
additionalInformation_text