Change vol language without reboot

[luiz_silva]

Hi
Because of backup software requirement, we must change the volume language from C to C.UTF-8
These volumes are CIFS/NTFS only and already in production.

When issuing the vol lang command, there are some warnings like below:

This will change the NFS-visible file names for shared files.
This may confuse some UNIX systems, since they may cache directory entries
with the old mappings.  Some files may no longer be accessible by NFS.
The change might also affect snapmirror and snapvault relationships resulting
in data corruption. You might have to re-baseline these relationships.

Do you still wish to perform this change? [no]:yes
WAFL_check -f will detect NFS files that will no longer be accessible via NFS
Should the system be halted following this change so WAFL_check can be run? [yes]:no
Fri May 21 00:05:10 BRT [fas02: vol.language.changed:info]: Language on volume vol_posix_changed changed to C.UTF-8

The new language mappings will be available after reboot

So what does it means?  (The new language mappings will be available after reboot)

Because it is not so easy to do reboot anytime and I'd like to know what problems may we have if we do not reboot and continue to use those volumes.

Thanks,

[watan]

I would definitely plan for an outage if changing the volume language as recommended in the OnTap storage management guide .  Technically the first time cifs accesses a directory, that directory will be  converted to unicode. So during path lookups, all directories in the  path get converted.  Its the NFS side of the house that we're primarily concerned with and there may be some directories that have not been converted.   I would recommend schedule a maintenance window and follow the guide.

[mcope]

The primary impact the language setting has is on the conversion or translation of special characters in a filename.  CIFS clients can use some characters which NFS forbids (#, !, etc.) or doesn't even include in it's character set.  If your backup application is Unix based, you'll get errors and the affect files will probably be skipped during the backup sequence.  You can help mitigate some of this by setting the volume option 'create_ucode' and 'convert_ucode' to on.  The conversion process will add a small amount of system overhead so may not be recommended on systems consistently running >50% CPU

This was also an issue with old MacOS files (pre-G4 days) which allowed special characters and had a funky creation date that made files appear to have been created in the early 1900s.

[lovik_netapp]

unfortunately I don't have KB number with me but as soon as you set the language on volume it's in effect and you don't need to reboot the filer it's just an old bug.

would be happy if someone can put kb number or correct me if i am wrong.

[haimroman]

lovik_netapp said

unfortunately I don't have KB number with me but as soon as you set the language on volume it's in effect and you don't need to reboot the filer it's just an old bug.

would be happy if someone can put kb number or correct me if i am wrong.

From https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb1008 :

Solution ID: kb1008
Last updated: 28 JUL 2006

How does the volume language work with filer?

Technically you do not have to reboot after changing a volume's language, since both the on-disk and the in-memory translation tables have been changed to the the new language. But if error messages like "Error starting OEM char set" or "Error starting NFS char set" appear, then you should reboot, 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 you don't reboot.

[haimroman]

Also from https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb6726 :

Solution ID: kb6726

What are the implications of changing the language of a volume after
data has been written to it?

Note:
A reboot is required for the new language mappings (No reboot is
required for creating a new volume with a correct language)