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