骏马金龙

网名骏马金龙,钟情于IT世界里的各种原理和实现机制,强迫症重症患者。爱研究、爱翻译、爱分享。特借此一亩三分田记录自己成长点滴!!!
我本问道人,道心不坚,必将与道无缘!

man sm-notify(sm-notify命令中文手册)

本人译作集合:http://www.cnblogs.com/f-ck-need-u/p/7048359.html

sm-notify命令是用来发送重启通知信息给NFS对端的,在锁状态恢复过程中起着至关重要的作用。此命令的说明大多数和rpc.statd都相同。

SM-NOTIFY(8)                           System Manager's Manual                      SM-NOTIFY(8)

NAME
       sm-notify - 发送系统重启通知给NFS对端的工具

SYNOPSIS
       /usr/sbin/sm-notify [-dfn] [-m minutes] [-v name] [-p notify-port] [-P path]

DESCRIPTION
       文件锁不是持久文件系统状态的一部分。因此当主机重启时锁的状态会丢失。

       当远程主机重启时,网络文件系统必须能够探测到锁状态的丢失。当NFS客户端重启时,NFS服务
       端必须释放该客户端所申请的所有文件锁。在服务端重启后,客户端必须能够提醒服务端它所申
       请的所有文件锁。

       对于NFSv2和NFSv3,使用网络状态监控器Network Status Monitor(NSM)协议来通知NFS对端关于重
       启的事情。在Linux上,NSM服务进程由两个独立的用户空间程序组成:

          ● rpc.statd
              
              该守护进程用于监听其他主机的重启消息,并管理本地主机重启时需要通知的主机列表。

          ● sm-notify
              一个辅助程序,用于在本地系统重启时通知NFS对端。
          
        (译者注:也就是说rpc.statd是重启信息的接收者,而sm-notify是信息的通知者)

       本地NFS锁管理器(NFS lock manager,NLM)会它本地的rpc.statd发出警告说列表中的每个远程对端
       状态都需要被监控。当本地系统重启时,sm-notify命令会通知对端上的NSM服务关于自己重启的
       事。当远程主机重启时,远程对端的sm-notify通知本地的rcp.statd,然后将此信息告诉本地NFS
       锁管理器,本地锁管理器将维护与重启端对应文件的锁。

NSM OPERATION IN DETAIL
       NFS客户端和服务端之间的第一个文件锁交互行为会使得两端的NLM都去联系它们本地的NSM服务以
       存储它们对端的信息。在Linux上,也就是让本地所管理器去联系rpc.statd守护进程。

       rpc.statd会将NFS对端信息记录在持久存储上。该信息描述了如果本地系统重启时如何去联系远程
       对端,如何识别对端报告它在重启的信息,以及当对端说它已经重启完成时如何通知NLM。

       每个客户端在每个文件锁请求中都会发送一个称为客户端caller_name的主机名。NFS服务端可以使
       用该主机名向客户端发送异步GRANT调用,或者通知客户端它已经重启完成。

       Linux NFS服务端可以将客户端的caller_name或客户端的网络地址提供给rpc.statd。为了遵守NSM
       协议,该名称或地址被称为对端mon_name。另外,本地锁管理器会告诉rpc.statd它自己的主机名,
       为了遵守NSM协议,该主机名被称为my_name。

       在NFS中,NFS服务端没有通知客户端它的主机名的交互行为。因此NFS客户端实际上不知道服务端
       的mon_name,尽管在SM_NOTIFY请求中会使用的它。Linux NFS客户端是通过使用从挂载命令中获取
       到的服务端主机名或地址来识别正在启动的NFS服务端的。

   Reboot notification
       当本地系统重启时,本地的sm-notify命令从持久存储中读取监控对端列表,并发送SM_NOTIFY请求
       给列表中每个远程对端的NSM服务进程,它使用mon_name字符串来指定发送目标。为了识别哪个主
       机已经重启完成,重启后的主机会使用sm-notify命令发送my_name字符串。远程rpc.statd将使用
       该字符串与其监控列表中的对端相匹配以找出发送SM_NOTIFY请求的主机。
       
       如果rpc.statd在它的监控列表中未找到能匹配接收到的SM_NOTIFY请求的对端,则通知不会被转发
       给本地锁管理器。另外,每个对端都独有一个32位整数NSM状态码,在每次重启之后,sm-notify命
       令都会让它碰撞重复。rpc.statd使用该号码来区分是重启还是通知重放。

       NFS锁恢复的一部分是重新发现哪个对端需要被再次监控。在每次重启之后,sm-notify命令都会清
       空持久存储上的监控列表。

OPTIONS
       -d     将sm-notify附在它的控制终端上并前台运行,使得通知程序可以直接被监控。
       
       -f     发送通知信息,即使自上次系统重启后sm-notify已经运行过一次了。

       -m retry-time
              指定当接收不到响应时,在此时间段内重发通知,单位为分钟。如果未指定,则sm-notify尝试
              在15分钟内一直发送通知。指定为0时,sm-notify将无限发送通知,直到它被手动kill掉。

              在以下几种情况时会重发通知:发送失败,远程主机未响应,远程NSM服务未注册,远程mon_name
              解析为IP地址时的DNS错误。

              只有接收到了远程主机的有效回应时,才会将此远程主机从通知列表中移除。但是SM_NOTIFY中
              还保留一个结果。sm-notify没有任何办法可以让远程主机识别发送者以及是否已经正确地恢复
              了锁状态。

       -n     阻止sm-notify更新本地系统的NSM状态号码。
       
       -p port
              指定sm-notify发送系统重启通知时的源端口号。若未指定,则使用随机临时端口号。
              
              该选项在通知需要穿越防火墙时可能会用上。

       -P, --state-directory-path pathname
              指定NSM状态信息保存路径的父目录。若未指定,则默认为/var/lib/nfs/statd。
              
              sm-notify启动之后,sm-notify将尝试使用UID/GID设置该目录的所有者和所属组。

       -v ipaddr | hostname
              指定发送系统重启通知时要使用的源网络地址,以及发送SM_NOTIFY请求时的mon_name参数的值。
              如果未指定该选项,则sm-notify将使用通配地址做源地址,并使用my_name作为发送SM_NOTIFY
              请求时的mon_name。

              如果指定了该选项,则sm-notify将转换IPV4地址为主机名,作为发送SM_NOTIFY请求时的mon_name。
              
              该选项比较适合用于多网卡接口的主机上,特别是远程对端需要从指定地址接收通知时。

ADDITIONAL NOTES
       主机重启后的锁恢复对于维护数据一致性和防止不必要的应用程序挂起至关重要。为了能让
       rpc.statd更高效地匹配SM_NOTIFY请求,应该遵守一些最佳实践,包括:

              系统的UTS名称需要和NFS对端用来做联系的DNS名称相匹配。
              (注:若不知何为UTS名,可以简单地认为UTS名称就是主机名)

              系统的UTS名称应该总是fqdn格式的名称。

              系统的UTS名的正向和反向DNS映射最好要保持一致。

              客户端用来挂载的服务端的主机名最好能匹配它所发送的SM_NOTIFY请求中的mon_name。

       卸载NFS文件系统时无需停止客户端或服务端任意一端的状态监控。两端可能会继续保持监控一段
       时间,以防这两端间后续再次出现新的挂载和额外的文件锁的NFS流量出现。

       在Linux上,如果没有装在内核锁模块,所有的远程NFS对端都不会被监控。这可能会发生在NFS的
       客户端上,例如,自动挂载工具移除了所有NFS挂载点,因为它们处于空闲非活动状态。



IPv6 and TI-RPC support
       TI-RPC is a pre-requisite for supporting NFS on IPv6. If TI-RPC support is built into rpc.statd,
       it attempts to start listeners on network transports  marked 'visible' in /etc/netconfig. As
       long as at least one network transport listener starts successfully, rpc.statd will operate.

FILES
       /var/lib/nfs/statd/sm    directory containing monitor list

       /var/lib/nfs/statd/sm.bak
                                directory containing notify list

       /var/lib/nfs/statd/state NSM state number for this host

       /proc/sys/fs/nfs/nsm_local_state
                                kernel's copy of the NSM state number

SEE ALSO
       rpc.statd(8), nfs(5), uname(2), hostname(7)

       RFC 1094 - "NFS: Network File System Protocol Specification"
       RFC 1813 - "NFS Version 3 Protocol Specification"
       OpenGroup Protocols for Interworking: XNFS, Version 3W - Chapter 11

AUTHORS
       Olaf Kirch <okir@suse.de>
       Chuck Lever <chuck.lever@oracle.com>

                                  1 November 2009                                       SM-NOTIFY(8)

以下是NFS相关翻译篇:

翻译:man rpcbind(rpcbind中文手册)
翻译:man nfsd(rpc.nfsd中文手册)
翻译:man mountd(rpc.mountd中文手册)
翻译:man statd(rpc.statd中文手册)
翻译:man sm-notify(sm-notify命令中文手册)
翻译:man exportfs(exportfs命令中文手册)
部分翻译:man nfs

posted @ 2017-08-08 00:35  骏马金龙  阅读(...)  评论(...编辑  收藏