Documentation_filesystems_nfs

Chinese translated version of Documentation\filesystems\nfs




If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.




Chinese maintainer: biyu tang<tangbiyu17@qq.com>
---------------------------------------------------------------------
DocumentationDocumentation\filesystems\nfs的中文翻译




如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。




中文版维护者： 唐碧瑜  biyu tang<tangbiyu17@qq.com>
中文版翻译者： 唐碧瑜  biyu tang<tangbiyu17@qq.com>
中文版校译者： 唐碧瑜  biyu tang<tangbiyu17@qq.com>




















以下为正文
---------------------------------------------------------------------
The NFS client
==============
NFS 客户端


The NFS version 2 protocol was first documented in RFC1094 (March 1989).
Since then two more major releases of NFS have been published, with NFSv3
being documented in RFC1813 (June 1995), and NFSv4 in RFC3530 (April
2003).


NFS版本2协议最早记载于RFC1094（1989年3月）.从那以后已经发布了两个更主要
的NFS版本，NFSv3被记录在RFC1813（1995年6月），NFSv4被记录在RFC3530（2003年4月）。


The Linux NFS client currently supports all the above published versions,
and work is in progress on adding support for minor version 1 of the NFSv4
protocol.


Linux NFS客户端目前支持所有上述已经发布的版本，并且将他加入到支持NFSv4
协议的小型版本1的工作正在进行中。


The purpose of this document is to provide information on some of the
special features of the NFS client that can be configured by system
administrators.


这个文档的目的就是提供一些关于NFS客户端的特殊功能的信息，从而使系统
管理员能够进行配置。


The nfs4_unique_id parameter
============================
nfs4_unique_id的参数


NFSv4 requires clients to identify themselves to servers with a unique
string.  File open and lock state shared between one client and one server
is associated with this identity.  To support robust NFSv4 state recovery
and transparent state migration, this identity string must not change
across client reboots.


NFSv4需要通过一个独特的字符串使客户端能在在服务器上区分自己。一个客
户端和一个服务器之间共享文件的打开和锁定状态与此标识相关。为了支持稳
定的NFSv4状态恢复和透明状态迁移。在客户端重新启动中这个标识字符串必须
不能改变。


Without any other intervention, the Linux client uses a string that contains
the local system's node name.  System administrators, however, often do not
take care to ensure that node names are fully qualified and do not change
over the lifetime of a client system.  Node names can have other
administrative requirements that require particular behavior that does not
work well as part of an nfs_client_id4 string.


如果没有其它的干预下，Linux客户段使用一个包含本地系统节点名称的字符串。
然而，系统管理员往往不能小心的确保节点名称完全符合要求，并且在客户端系
统的整个生命周期都不发生改变。节点名称可以通过特定行为达到其他管理上的
要求，但不能很好的作为一个nfs_client_id4字符串的一部分。


The nfs.nfs4_unique_id boot parameter specifies a unique string that can be
used instead of a system's node name when an NFS client identifies itself to
a server.  Thus, if the system's node name is not unique, or it changes, its
nfs.nfs4_unique_id stays the same, preventing collision with other clients
or loss of state during NFS reboot recovery or transparent state migration.


nfs.nfs4_unique_id引导参数指定一个特定的字符串可以用来代替系统的节点名称，
当一个NFS客户端能够在一台服务器上标识自己。因此，如果系统的节点名称不是唯
一的，或使会改变的，它的nfs.nfs4_unique_id保持不变，防止在NFS重启恢复或透明
状态迁移过程中与其他客户端发生冲突或状态丢失。


The nfs.nfs4_unique_id string is typically a UUID, though it can contain
anything that is believed to be unique across all NFS clients.  An
nfs4_unique_id string should be chosen when a client system is installed,
just as a system's root file system gets a fresh UUID in its label at
install time.


nfs.nfs4_unique_id字符串是一个典型的UUID，尽管它可以包含任何在所有NFS客
户端上被认定是唯一的东西。一个nfs4_unique_id字符串在安装客户端系统时就
应该被选择，就像一个系统的根文件系统在安装时标签中得到一个新的UUID。


The string should remain fixed for the lifetime of the client.  It can be
changed safely if care is taken that the client shuts down cleanly and all
outstanding NFSv4 state has expired, to prevent loss of NFSv4 state.


该字符串应该在客户端的生命周期内保持固定。它可以在客户端完全关闭并且所有
突出的NFSv4状态都已经过期时安全的修改，以防止NFSv4状态的丢失。


This string can be stored in an NFS client's grub.conf, or it can be provided
via a net boot facility such as PXE.  It may also be specified as an nfs.ko
module parameter.  Specifying a uniquifier string is not support for NFS
clients running in containers.


此字符串可以被存储在一个NFS客户端的grub.conf中，或者它可以通过网络引
导设施被提供就像PXE。它也可能被指定作为一个nfs.ko模块参数。指定一个更
加特殊的字符串不是在容器中运行的NFS客户端所支持的。


The DNS resolver
================
DNS解析


NFSv4 allows for one server to refer the NFS client to data that has been
migrated onto another server by means of the special "fs_locations"
attribute. See
http://tools.ietf.org/html/rfc3530#section-6
and
http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00


NFSv4允许一台服务器查询NFS客户机已经迁移到另一台服务器上的数据，通过
”fs_locations“的特殊属性。
参见 http://tools.ietf.org/html/rfc3530#section-6
和 http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00


The fs_locations information can take the form of either an ip address and
a path, or a DNS hostname and a path. The latter requires the NFS client to
do a DNS lookup in order to mount the new volume, and hence the need for an
upcall to allow userland to provide this service.


fs_locations信息可以采取的形式可以是IP地址和路径，或DNS主机名和路径。后
者需要NFS客户端做一个DNS查找，以装载新的容量，因此需要一个上调，允许用户
级提供这项服务。


Assuming that the user has the 'rpc_pipefs' filesystem mounted in the usual
/var/lib/nfs/rpc_pipefs, the upcall consists of the following steps:


假设该用户有'rpc_pipefs'的文件系统安装在通常的的/ var/ lib中/ NFS/ rpc_pipefs中，
那么上行调用包括以下步骤：
   
   (1) The process checks the dns_resolve cache to see if it contains a
       valid entry. If so, it returns that entry and exits.


  （1）进程检查dns_resolve的的缓存，以查看它是否包含有效的项目。如果是的话，
  则它返回该条目，然后退出。
  
   (2) If no valid entry exists, the helper script '/sbin/nfs_cache_getent'
       (may be changed using the 'nfs.cache_getent' kernel boot parameter)
       is run, with two arguments:
- the cache name, "dns_resolve"
- the hostname to resolve

（2）如果没有有效的条目存在，辅助脚本‘/ sbin/ nfs_cache_getent’（可以通过
'nfs.cache_getent‘的内核引导参数改变）运行时，有两个参数：
-缓存名称，“dns_resolve”
        - 主机名解析


   (3) After looking up the corresponding ip address, the helper script
       writes the result into the rpc_pipefs pseudo-file
       '/var/lib/nfs/rpc_pipefs/cache/dns_resolve/channel'
       in the following (text) format:


"<ip address> <hostname> <ttl>\n"


       Where <ip address> is in the usual IPv4 (123.456.78.90) or IPv6
       (ffee:ddcc:bbaa:9988:7766:5544:3322:1100, ffee::1100, ...) format.
       <hostname> is identical to the second argument of the helper
       script, and <ttl> is the 'time to live' of this cache entry (in
       units of seconds).


  Note: If <ip address> is invalid, say the string "0", then a negative
       entry is created, which will cause the kernel to treat the hostname
       as having no valid DNS translation.
  
  （3）找到相应的IP地址后，辅助脚本将结果写入到的rpc_pipefs伪文件
       '/ var/ lib/ NFS/ rpc_pipefs/cache/ dns_resolve/channel'在下面的（文
  本）的格式中："<ip address> <hostname> <ttl>\n"
  
   其中<IP地址>通常是IPv4（123.456.78.90）或IPv6（FFEE：DDCC：BBAA：9988:7766:5544:3322:
  1100 FFEE的::1100，...）格式。<hostname>和辅助脚本的第二个参数相同，<TTL>的是高
  速缓存条目的'生存时间’（单位为秒）。
  
  注：如果<ip地址>是无效的，显示了一串“0”，则负项将被创建，这将导致内核处理主机
  名没有有效的DNS翻译。
  
  
  
A basic sample /sbin/nfs_cache_getent
=====================================


#!/bin/bash
#
ttl=600
#
cut=/usr/bin/cut
getent=/usr/bin/getent
rpc_pipefs=/var/lib/nfs/rpc_pipefs
#
die()
{
echo "Usage: $0 cache_name entry_name"
exit 1
}


[ $# -lt 2 ] && die
cachename="$1"
cache_path=${rpc_pipefs}/cache/${cachename}/channel


case "${cachename}" in
dns_resolve)
name="$2"
result="$(${getent} hosts ${name} | ${cut} -f1 -d\ )"
[ -z "${result}" ] && result="0"
;;
*)
die
;;
esac
echo "${result} ${name} ${ttl}" >${cache_path}