在写入数据后更改卷的语言会产生什么影响？
适用于
Data ONTAP 7 及更早版本
解答
- 每个卷都有一种语言。
卷的语言决定了 Data ONTAP 显示该卷的文件名和数据时所使用的字符集。
此语言设置仅影响文件名，不影响文件中的数据
- 卷语言用于将传入的 NFSv3 名称转换为 Unicode 。
卷语言还用于将现有的 Unicode 目录名称转换为 NFS 编码、然后再从 NFS Redir 操作返回名称。
- 因此，建议在将数据写入卷之前设置卷语言。
但是，在写入数据后可能需要更改卷语言。
为了了解写入数据后更改卷语言的含义、我们需要了解如何创建数据。
- 如果文件是由 Windows CIFS 客户端创建的、则它们将以 Unicode 存储在目录中。
文件名的显示和从 Windows CIFS 的访问将使用 Unicode ， Windows 可以看到非 ASCII 字符。
但是对于 NFSv3 ，只有 Unicode 范围中的字符可以翻译并对 NFS 客户端可见。
其他字符不会转换、因此文件将通过 NFS 备用名称从 NFS 中看到和访问。
NFSv4 不是一个问题，因为它需要使用 UTF-8 。
- 如果将卷语言更改为 UTF-8 、则任何现有的 Unicode 名称都可以始终转换为 UTF-8 、因此需要 UTF-8 的正确编码的 NFSv3 客户端应该能够可靠地对这些名称进行操作。
当 Windows 客户机看到这些名称时，这些名称也会正确无误，因为 CIFS 始终需要 Unicode 名称。
- 如果文件是由 NFSv3 创建的、且文件名包含无效字符、则文件名将存储为提供的确切字节。
这是因为这些字符不能转换为 Unicode ，当客户端错误地对名称进行编码时可能会发生这种情况。
- 在这种情况下、不执行任何转换、 NFSv3 将看到该文件并使用创建时给定的完全相同的字节对其进行访问。
由于它不会转换为 Unicode 、因此 Windows 只会看到该文件的 8.3 名称。
- 如果将语言更改为 UTF-8 且这些字节发生为有效的 UTF-8 ，则对该文件的访问将把 UTF-8 转换为 Unicode 并尝试查找具有该 Unicode 名称的文件。
如果存在，则将是访问的文件、而不是目标文件。
如果不存在某个文件、则会出现错误、即使读取的目录显示了这样的文件。
- 在这种情况下，如果为 UTF-8 复制配置 NFS 客户端或将文件重命名为使用 UTF-8 编码的卷，则可以恢复 CIFS 使用的正确名称。
这可以解决该问题，因为客户端发送的编码与卷语言匹配。
卷语言更改和复制含义
- 如果卷仅包含 Windows OSSV 数据的副本，则不应引起关注。
- 如果满足以下所有条件、则除了在发生故障时重新初始化 SnapVault 或 qtree SnapMirror 关系之外、没有任何解决方法
- 该卷包含非 Unicode 源的副本 qtree ，即：
- 通用 Internet 文件系统 (CIFS) 协议未访问的存储系统 qtree 以及卷选项 create_ucode 和 convert_ucode 均处于关闭状态。
- 非 Windows OSSV 主数据。
- 卷已打开 create_ucode 、辅助卷未打开。
- 主数据具有非 ASCII 文件名、同一目录中有多个硬链接（不是同一目录树、而是同一目录）。
- 对于不属于上述任一类别的副本数据：
- 辅助卷上的 NFS 访问可能会受到影响（名称看起来很奇怪、或者您只能看到 NFS 备用名称（例如： 8U10000 ）、直到主卷上发生目录操作、并且成功更新操作完成。
- 在这种情况下，要加快恢复速度，请重命名主目录上的每个非 ASCII 文件名。理想情况下，您可以将每个文件名重命名为另一个目录，然后将其重命名为原始位置。然后正确更新 SnapVault/SnapMirror 。
其他信息
有关在 ONTAP 9 中更改卷语言的信息，请参见 在 ONTAP 9 中创建卷后是否可以更改卷的语言？