データが書き込まれた後でボリュームの言語を変更すると、どのような影響がありますか。
に適用されます
Data ONTAP 7 以前
回答
- すべてのボリュームに言語があります。
ボリュームの言語によって、そのボリュームのファイル名やデータを表示するためにData ONTAPで使用される文字セットが決まります。
この言語設定はファイル名にのみ影響し、ファイル内のデータには影響しません
- ボリューム言語は、着信 NFSv3 名を Unicode に変換するために使用されます。
ボリューム言語は、 NFS readdir 操作から名前を返す前に、既存の Unicode ディレクトリ名を NFS エンコードに変換するためにも使用されます。
- そのため、ボリュームにデータを書き込む前に、ボリューム言語を設定することをお勧めします。
ただし、データの書き込み後にボリューム言語を変更する必要がある場合もあります。
データの書き込み後にボリューム言語を変更した場合の影響を理解するには、データがどのように作成されたかを確認する必要があります。
- Windows CIFS クライアントによって作成されたファイルは、 Unicode でディレクトリに保存されます。
ファイル名と Windows CIFS からのアクセスの表示には Unicode が使用され、 ASCII 以外の文字が Windows に表示されます。
ただし、 NFSv3 では、 Unicode 範囲の文字のみが変換可能であり、 NFS クライアントから認識されます。
他の文字は変換されないため、ファイルは NFS の代替名で表示され、 NFS からアクセスされます。
NFSv4 では UTF-8 を使用する必要があるため、問題はありません。
- ボリューム言語を UTF-8 に変更すると、既存の Unicode 名は常に UTF-8 に変換されるため、 UTF-8 を必要とする適切にエンコードされた NFSv3 クライアントは、そのような名前に対して確実に動作できるようになります。
CIFS は常に Unicode 名を想定しているため、 Windows クライアントではこれらの名前も正しく表示されます。
- ファイルが NFSv3 で作成され、ファイル名に無効な文字が含まれている場合、ファイル名は指定されたバイトとして正確に保存されます。
これは、これらの文字を Unicode に変換できず、クライアントによって名前が正しくエンコードされない場合に発生する可能性があるためです。
- このような場合、変換は行われず、 NFSv3 はファイルを認識し、作成時に指定されたバイトとまったく同じバイト数でファイルにアクセスします。
Unicode に変換されないため、 Windows ではファイルの 8.3 形式の名前のみが表示されます。
- 言語が UTF-8 に変更され、そのバイトが有効な UTF-8 である場合、ファイルへのアクセスによって UTF-8 が Unicode に変換され、その Unicode 名を持つファイルが検索されます。
ファイルが存在する場合は、そのファイルがアクセスされますが、目的のファイルではありません。
ディレクトリが存在しない場合は、読み取りディレクトリにそのようなファイルが表示されていても、エラーが発生します。
- このようなシナリオでは、 NFS クライアントが UTF-8 コピー用に構成されている場合、またはファイルの名前を UTF-8 エンコードのボリュームに変更した場合に、 CIFS で使用する正しい名前をリカバリできます。
クライアントから送信されたエンコーディングがボリューム言語と一致するため、この問題は解決されます。
ボリューム言語の変更とレプリケーションの影響
- ボリュームに Windows OSSV データのレプリカのみが含まれている場合は、問題の原因はありません。
- 次の条件がすべて満たされている場合は、 SnapVault 関係または qtree SnapMirror 関係が失敗した場合の再初期化以外の回避策はありません
- ボリュームには、 Unicode に対応していないソースのレプリカ qtree が含まれます。つまり、次のようになります。
- Common Internet File System （ CIFS ）プロトコルでアクセスされず、ボリュームオプション create_ucode と convert_ucode の両方がオフになっているストレージシステム qtree 。
- Windows 以外の OSSV プライマリデータ。
- ボリュームの create_ucode がオンになっており、セカンダリがオンになっていません。
- プライマリデータのファイル名は ASCII 以外で、同じディレクトリに複数のハードリンクがあります（同じディレクトリツリーではなく、同じディレクトリ）。
- レプリカデータが上記のいずれのカテゴリにも分類されない場合：
- セカンダリボリュームでの NFS アクセスは、プライマリでディレクトリ操作が行われ、正常な更新処理が完了するまで、（名前が奇数になるか、 8U10000 などの NFS 代替名のみが表示される）障害になる可能性があります。
- この場合、リカバリを高速化するには、プライマリ上の非 ASCII ファイル名をそれぞれ変更します。理想的には、それぞれのディレクトリの名前を別のディレクトリに変更してから、元の位置に名前を変更します。その後、 SnapVault と SnapMirror が正しく更新されます。
追加情報
AdditionalInformation_Text