ボリュームの言語は、 Data ONTAP 7-Mode を実行するストレージシステムでどのように動作しますか。

に適用されます

Data ONTAP 7-Mode でサポートされています

回答

すべて

のボリュームに言語が設定されているシステムに影響がないかどうかを Active IQ で確認してください。ストレージシステムでは、言語に適した文字セットが使用されます。ボリュームの言語は、ボリュームの作成時に指定することも、作成後にあとから変更することもできます。デフォルトでは、ボリュームの言語はルートボリュームの言語と同じになります。ボリュームの言語を設定する必要がない場合もあります。状況に応じて次のようなものがあります。

1. ボリュームが NFS （ V4 より小さい）のみに使用される場合：
   何も実行しない（ただし、 Unicode クライアントによってファイルが作成されるタイミングは問題なし）
2. ボリュームが CIFS のみ、または NFSv4 以降に使用
   されている場合：ボリュームの言語は CIFS には関連しない。NFS の場合は、ボリュームの言語をクライアントの言語に設定します。
3. ボリュームが CIFS
   と NFS （ V4 より小さい）の両方に使用される場合は、ボリュームの言語を NFS で使用されるロケールに設定します。
4. create_ucode ボリュームオプションと convert_ucode ボリュームオプションをオンにして、ボリューム作成時にこれらのオプションをすぐに有効にします。
   vol options <volume_name> create_ucode on | off
vol options <volume_name> convert_ucode on | off
5. MSDOS などの下位レベルのレガシークライアント。 Unicode はサポートされません。Do require the volume language setting - これらのクライアントが使用する OEM 文字セットを提供します。
   レガシークライアントの場合は、通常の NFS 文字セットを提供する「 en 」ボリューム言語設定と、ドイツ語、スペイン語、フランス語などほとんどのヨーロッパ諸国を対象とする cp850 OEM 文字セットを使用します。それ以外の場合は、 NFS 文字セットと cp437 OEM 文字セットを提供する 'en_US' を使用します。これらの 2 つの違いは、関連cp850.hcp437.hするファイルとヘッダーファイルにあります。

ベストプラクティス： :

• すべてのボリュームが同じ言語であることが理想的です。ボリュームがコンソールの言語と異なる場合、パス名を指定したコマンドが機能しないことがあります。
• 一度設定した言語は変更しないでください。 
  言語を変更する必要がある場合は、ボリュームにファイルを作成する前に変更して、すべてのファイル名で同じ言語を使用するようにします。ボリュームでファイルが作成されたあとに言語を変更すると、一部の NFS エンコーディングが無効になる場合があります。ファイル名が読み取り不能になり、ファイルが見つからないため、ファイルにアクセスできなくなります。ボリュームの言語を変更する一番の方法は、必要な言語を設定して新しいボリュームを作成し、外部ソフトウェアを使用してそのボリュームにデータをコピーすることです。これにより、クライアントは期待どおりにエンコーディングを作成し、クライアントに正確に返すように Data ONTAP によって書き込みます。 
• Windows と UNIX から同じファイル名を表示するには、 NFS 文字セットでのみ、およびが有効な文字のみを使用します。
  たとえば、日本語のファイル名をフランス語のボリュームに配置しないでください。
• 技術的には、ボリュームの言語を変更した後に再起動する必要はありません。ディスク上の翻訳テーブルとメモリ内の翻訳テーブルの両方が新しい言語に変更されているからです。しかしError starting OEM char set、やなどのエラーメッセージError starting NFS char setが表示された場合は、メモリ不足などの理由で新しいメモリ内テーブルを構築できなかったため、再起動が必要になります。また、システムがリブートされないと、メモリに古いデータが表示される可能性があります。

データの書き込み後にボリュームの言語を変更すると、次のいずれかのカテゴリに該当する場合に多少の影響が生じる可能性があります。

1. ボリュームに Windows OSSV データのレプリカのみが含まれている場合は、問題の原因はありません。
2. 次の条件をすべて満たす場合は、 SnapVault 関係または qtree SnapMirror 関係の再初期化に失敗した場合を除き、対処方法はありません。
   1. Unicode 以外のソースのレプリカ qtree をボリュームに格納している。
      • Common Internet File System （ CIFS ；共通インターネットファイルシステム）プロトコルでアクセスされなかったストレージシステム qtree とボリュームオプションのcreate_ucodeconvert_ucode両方が off になっている qtree
      • Windows 以外の OSSV プライマリデータ
   2. ボリュームのcreate_ucode電源がオンになっており、セカンダリがオフになっています。  
   3. プライマリ・データには非 ASCII ファイル名があり ' 同じディレクトリ内に複数のハード・リンクがある（同じディレクトリ・ツリーではなく ' 同じディレクトリ）

レプリカデータが上記のいずれのカテゴリにも分類されない場合：

セカンダリボリュームでの NFS アクセスが機能喪失（名前が奇数に見えるか、または 8U10000 などの NFS 代替名のみを表示できる）。そのためには、プライマリでディレクトリ処理が発生して、更新処理が正常に完了します。

この場合は ' リカバリを高速化するために ' プライマリ上の各非 ASCII ファイル名の名前を変更しますこの場合は、各ディレクトリの名前を別のディレクトリに変更してから、元のディレクトリの名前に変更することをお勧めします。その後、 SnapVault と SnapMirror が正しく更新されます。

レプリカ以外のデータの場合：

1. ボリュームcreate_ucodeconvert_ucodeとオプションの両方が off で、 NFS データにアクセスする場合（ CIFS ではない）、問題はありません。
2. create_ucodeconvert_ucodeボリュームにまたはオプションが設定されている場合や NFS データにアクセスした場合は、 NFS の代替名に関連する問題が発生している可能性があります。
3. 0x7f を超える文字を持つファイルが Unicode 以外のディレクトリにある場合は、スイッチの後でそれらにアクセスする際に問題が発生します。これらが存在しないことが確実な場合は、すべて OK である必要があります。

Unicode ディレクトリにあるファイルの場合、 Unicode が限定的であり、問題は、これらの名前が指定した文字セットに基づいて変換されることです。そのため、クライアントが UTF8 名を受け入れるように設定されている場合は、すべて動作します。

拡張文字セット（例 日本語）ストレージシステム上の言語を変更しない場合は、

ボリュームの言語が UTF-8 言語セット（ en_US.UTF-8 ）を指定し、クライアントが 255 バイト未満のファイル名を書き込んでいる場合、言語を変更する必要はありません。ファイル名が非常に長い場合（ 85 文字を超える場合など）、各文字が 3 バイトの UTF-8 に変換されると、ファイル名が許容サイズを超え、ユーザが NFS からファイルにアクセスしようとした場合に、 NFS の代替名が表示されます。上の例では、言語をローカライズされたサポート言語に変更します（ ja_v1 ）では、日本語の文字ごとに 2 バイトを許可し、上記の 85 文字のファイル名は 255 ではなく 170 バイトのみとします。この場合でも、ファイル名が 128 文字に達すると、管理者はファイル名の制限の問題に対処できます。

追加情報

AdditionalInformation_Text