vol lang on src and det is different, will it have any implication on snapmirror & snapvault on the secondary ?

[ASHWINPAWARTESL]

vol lang on src and dest is different, will it have any implication on snapmirror & snapvault on the secondary ?

srv vol lang -> en_US

dest vol lang -> C (Posix)

Data is already mirrored to dest vol. Question is - Can I continue in the current state, or set vol lang on dest to 'en_US' and re-initialize the mirror ?

Thanks,

-Ashwin

[uptimenow]

Hi,

Check out these two KBs for a little more info:

https://kb.netapp.com/support/index?page=content&id=3010763

https://kb.netapp.com/support/index?page=content&id=3012005

In the past, there were some bugs related to QSM/SV and vol language settings. I vaguely remember an occurrence at a customer where some files on the destination system were not visible.

Anyway, hope this gets you going ...

[scottgelb]

Very good points and the second KB explains it really well.  We most often see en_US and C (Posix) and with CIFS most have unicode enabled so it isn't used.  UTF-8 was also almost required early on with OSSV (been a while but remember issues without it) and I remember mostly on OSSV targets.

Another consideration is the migration to Clustered ONTAP (C-Mode).  All volumes in a Vserver must be the same language, so if the source volumes have different languages they can't be put in the same target Vserver (unless the languages are changed to match and a lot of caveats listed in doing that).  Most will have a road map (hardware lifecycle event, new netapp needed, etc.) to go to Clustered ONTAP so vol lang is important if the volume transition wizard using SnapMirror is used...other wise looking at changing source volumes or using a host based copy method may be needed.  There will also likely be newer migration tools that can mitigate this but something we are keeping in mind when auditing current 7-mode systems to future proof them.

[l_mitchell]

Hi Scott,

Interesting you raised the UTF-8 option above, I am currently deploying NetApp SnapProtect aka rebadged CommVault, and I'm struggling to as to why they recommend the below statement and whether I should implement it or not on my volumes (then you suddenly bring it up, so I'm hoping you could provide a NetApp techie explanation!)

What UTF Setting should be used for Volume Language?

To successfully browse and restore files on a NetApp file server that contain
Unicode characters, it is recommended to use the UTF-8 setting for volume
language. Please consult with NetApp for implications of changing volume
language.

I dont suppose you could provide your interpretation on the above (very generic!) statement. Does it read I should use UTF-8 for <any?> volume that was created with the create_ucode vol option turned on that I will be protecting, which is probably most NetApp volumes? It may well be talking about only for the destination volumes of a snapvault relationship. And only CIFS shares at that, I should be fine for NFS mounts to VMware say?

A colleague asked if I was using extended character sets such as Korean (the answer to which was no), if not I should be OK. The documentation is simply rebadged CommVault documentation so it may be a piece of legacy information that no longer matters? The main thing is I can do test restores just fine...

Also could I ask you if this is an option you would normally only turn on just for CIFS shares, or as a generic option you would enable from vol0 say so it is inherited for all future created vols? And if it does turn out that enabling UTF-8 is a good idea in your opinion what things I should watch out for? It seems to want a reboot of the filer by changing it on a test volume, so any advice welcome here (assuming its required!)

Like I said it must be fate that you mentioned it as I can't find any useful info around UTF-8, so I'm hoping you can at least point me in the right direction.

Thanks!

[scottgelb]

You are right that the coverage is generic and not a lot of explanation.  There are some good links on encoding... I tend to turn ucode on for the root volume on a new install and most use either C (Posix) or en_US in our area.

For SnapVault backup targets with ossv I use C.UTF-8 or en_US.UTF-8 for those volumes and looks like a similar use for Commvault.  The links explain some of the impact of UTF-8 and the encoding.

http://en.wikipedia.org/wiki/UTF-8

http://www.utf-8.com/

http://www.fileformat.info/info/unicode/utf8.htm

[l_mitchell]

Thanks for the quick reply.

I've just noticed that the vol language was set to <source vol lang>.UTF-8 on the destination, so there you go, I guess as SnapProtect relies on DFM to create SV relationships, that the DFM volume provisioning part has set best practice settings for me! If only they put that sort of stuff in the documentation in the first place..! If you're configuring it via the cli for import later....etc.

Thanks again.

[ASHWINPAWARTESL]

Thanks everyone for your inputs. Frankly, I actually never cared much for the LANG setting before (thanks to this thread), without actually giving much thought I would set it as 'en_US' (en_US uses ASCII encoding, and en_US.utf8 uses UTF8 (Unicode) encoding. Since UTF8 is a superset of ASCII, it's the default). I think whatever be it POSIX C or en_US, as long as 'ucode' is set to on, you are good. Is that right?

[aborzenkov]

Unfortunately those links do not explain NetApp usage of encoding. It was always a poorly documented subject. Until now I have not seen any explanation, what actually setting of volume language changes.

Отправлено с iPhone

04.03.2013, в 20:23, "Scott Gelb" <xdl-communities@communities.netapp.com<mailto:xdl-communities@communities.netapp.com>> написал(а):

<https://communities.netapp.com/index.jspa>

Re: vol lang on src and det is different, will it have any implication on snapmirror & snapvault on the secondary ?

created by Scott Gelb<https://communities.netapp.com/people/scottgelb> in Data ONTAP - View the full discussion<https://communities.netapp.com/message/101737#101737>

You are right that the coverage is generic and not a lot of explanation. There are some good links on encoding... I tend to turn ucode on for the root volume on a new install and most use either C (Posix) or en_US in our area.

For SnapVault backup targets with ossv I use C.UTF-8 or en_US.UTF-8 for those volumes and looks like a similar use for Commvault. The links explain some of the impact of UTF-8 and the encoding.

http://en.wikipedia.org/wiki/UTF-8

http://www.utf-8.com/

http://www.fileformat.info/info/unicode/utf8.htm

Reply to this message by replying to this email -or- go to the message on NetApp Community<https://communities.netapp.com/message/101737#101737>

Start a new discussion in Data ONTAP by email<mailto:discussions-community-products_and_solutions-data_ontap@communities.netapp.com> or at NetApp Community<https://communities.netapp.com/choose-container.jspa?contentType=1&containerType=14&container=2877>

[scottgelb]

And Some of the docs say that vol Lang doesn't matter when Unicode is enabled with cifs which makes it more confusing.

Sent from my iPhone 5

[l_mitchell]

So by default Unicode enable on a source volume is UTF-16, hence why vol lang isn't really relevant, as it can support pretty much all extended character sets (this is me putting 2+2 together here to possibly make 5!).

But then if a SV destination has a best practice of UTF-8 it begs the question could you potentially lose some extended characters in file names assuming that they were used? Highly unlikely that it may be though, for us at least. Like I said I'm guessing here.