本文目錄：

1.1 概述

1.2 RPC不可不知的原理

1.2.1 RPC原理

1.2.2 RCP工具介紹

1.3 啟動NFS

1.4 配置導出目錄和掛載使用

1.4.1 配置NFS導出目錄

1.4.2 掛載NFS文件系統

1.4.3 NFS偽文件系統

1.5 showmount命令

1.6 NFS身份映射

1.7 使用exportfs命令導出目錄

1.8 深入NFS的方向

1.1 概述

類似ext家族、xfs格式的本地文件系統，它們都是通過單個文件名稱空間(name space)來包含很多文件，並提供基本的文件管理和空間分配功能。而文件是存放在文件系統中(上述名稱空間內)的單個命名對象，每個文件都包含了文件實際數據和屬性數據。但是，這些類型的文件系統和其內文件都是存放在本地主機上的。

實際上，還有網路文件系統。顧名思義，就是跨網路的文件系統，將遠程主機上的文件系統(或目錄)存放在本地主機上，就像它本身就是本地文件系統一樣。在Windows環境下有cifs協議實現的網路文件系統，在Unix環境下，最出名是由NFS協議實現的NFS文件系統。

NFS即network file system的縮寫，nfs是屬於用起來非常簡單，研究起來非常難的東西。相信，使用過它或學過它的人都不會認為它的使用有任何難點，只需將遠程主機上要共用給客戶端的目錄導出(export)，然後在客戶端上掛載即可像本地文件系統一樣。到目前為止，nfs已經有5個版本，NFSv1是未公佈出來的版本，v2和v3版本目前來說基本已經淘汰，v4版本是目前使用最多的版本，nfsv4.1是目前最新的版本。

1.2 RPC不可不知的原理

要介紹NFS，必然要先介紹RPC。RPC是remote procedure call的簡寫，人們都將其譯為"遠程過程調用"，它是一種框架，這種框架在大型公司應用非常多。而NFS正是其中一種，此外NIS、hadoop也是使用rpc框架實現的。

1.2.1 RPC原理

所謂的remote procedure call，就是在本地調用遠程主機上的procedure。以本地執行"cat -n ~/abc.txt"命令為例，在本地執行cat命令時，會發起某些系統調用(如open()、read()、close()等)，並將cat的選項和參數傳遞給這些函數，於是最終實現了文件的查看功能。在RPC層面上理解，上面發起的系統調用就是procedure，每個procedure對應一個或多個功能。而rpc的全名remote procedure call所表示的就是實現遠程procedure調用，讓遠程主機去調用對應的procedure。

上面的cat命令只是本地執行的命令，如何實現遠程cat，甚至其他遠程命令？通常有兩種可能實現的方式：

(1).使用ssh類的工具，將要執行的命令傳遞到遠程主機上並執行。但ssh無法直接調用遠程主機上cat所發起的那些系統調用(如open()、read()、close()等)。

(2).使用網路socket的方式，告訴遠程服務進程要調用的函數。但這樣的主機間進程通信方式一般都是daemon類服務，daemon類的客戶端(即服務的消費方)每調用一個服務的功能，都需要編寫一堆實現網路通信相關的代碼。不僅容易出錯，還比較複雜。

而rpc是最好的解決方式。rpc是一種框架，在此框架中已經集成了網路通信代碼和封包、解包方式(編碼、解碼)。以下是rpc整個過程，以cat NFS文件系統中的a.sh文件為例。

nfs客戶端執行cat a.sh，由於a.sh是NFS文件系統內的文件，所以cat會發起一些procedure調用(如open/read/close)，這些procedure和對應的參數會發送給rpc client(可能是單個procedure，也可能是多個procedure組合在一起一次性發送給rpc client，在NFSv4上是後者)，rpc client會將這些數據進行編碼封裝(封裝和解封裝功能由stub代碼實現)，然後將封裝後的數據通過網路發送給rpc server，rpc server會對封裝的數據進行解封，於是就得到了要調用的procedures和對應的參數，然後將它們交給NFS服務進程，最終進行procedure的調用。NFS服務發起procedure調用後，會得到數據(可能是數據本身，可能是狀態消息等)，於是交給rpc server，rpc server會將這些數據封裝並通過網路發送給rpc client，rpc client解封於是得到最終的返回結果。

從上面的過程可以知道，rpc的作用是數據封裝，rpc client封裝待調用的procedure及其參數，rpc server封裝返回的數據。

所以註意，rpc的遠程procedure調用的概念不是在本地向遠程主機發起procedure的調用，而是將要執行的procedure包裝後通過rpc發送出去，讓遠程主機上的對應程式自己去執行procedure並返回數據。也就是說rpc的作用是封裝和發送，而不是發起調用。

舉個更簡單的例子，使用google搜索時，實現搜索功能的procedure和要搜索的內容就是rpc client封裝的對象，也是rpc server要解封的對象，搜索的結果則是rpc server封裝的對象，也是rpc client要解封的對象。解封後的最終結果即為google搜索的結果。

1.2.2 RPC工具介紹

在CentOS 6/7上，rpc server由rpcbind程式實現，該程式由rpcbind包提供。

[root@xuexi ~]# yum -y install rpcbind

[root@xuexi ~]# rpm -ql rpcbind | grep bin/
/usr/sbin/rpcbind
/usr/sbin/rpcinfo

其中rpcbind是rpc主程式，在rpc服務端該程式必須處於已運行狀態，其預設監聽在111埠。rpcinfo是rpc相關信息查詢工具。

對於rpc而言，其所直接管理的是programs，programs由一個或多個procedure組成。這些program稱為RPC program或RPC service。

如下圖，其中NFS、NIS、hadoop等稱為網路服務，它們由多個進程或程式(program)組成。例如NFS包括rpc.nfsd、rpc.mountd、rpc.statd和rpc.idmapd等programs，其中每個program都包含了一個或多個procedure，例如rpc.nfsd這個程式包含瞭如OPEN、CLOSE、READ、COMPOUND、GETATTR等procedure，rpc.mountd也主要有MNT和UMNT兩個procedure。

對於RPC而言，它是不知道NFS/NIS/hadoop這一層的，它直接管理programs。每個program啟動時都需要找111埠的rpc服務登記註冊，然後RPC服務會為該program映射一個program number以及分配一個埠號。其中每個program都有一個唯一與之對應的program number，它們的映射關係定義在/etc/rpc文件中。以後rpc server將使用program number來判斷要調用的是哪個program中的procedure並將解包後的數據傳遞給該program。

例如只啟動rpcbind時。

[root@xuexi ~]# systemctl start rpcbind.service

[root@xuexi ~]# rpcinfo -p localhost
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper

其中第一列就是program number，第二列vers表示對應program的版本號，最後一列為RPC管理的RPC service名，其實就是各program對應的稱呼。

當客戶端獲取到rpc所管理的service的埠後，就可以與該埠進行通信了。但註意，即使客戶端已經獲取了埠號，客戶端仍會藉助rpc做為中間人進行通信。也就是說，無論何時，客戶端和rpc所管理的服務的通信都必須通過rpc來完成。之所以如此，是因為只有rpc才能封裝和解封裝數據。

既然客戶端不能直接拿著埠號和rpc service通信，那還提供埠號幹嘛？這個埠號是為rpc server提供的，rpc server解包數據後，會將數據通過此埠交給對應的rpc service。

1.3 啟動NFS

NFS本身是很複雜的，它由很多進程組成。這些進程的啟動程式由nfs-utils包提供。由於nfs是使用RPC框架實現的，所以需要先安裝好rpcbind。不過安裝nfs-utils時會自動安裝rpcbind。

[root@xuexi ~]# yum -y install nfs-utils

[root@xuexi ~]# rpm -ql nfs-utils | grep /usr/sbin
/usr/sbin/blkmapd
/usr/sbin/exportfs
/usr/sbin/mountstats
/usr/sbin/nfsdcltrack
/usr/sbin/nfsidmap
/usr/sbin/nfsiostat
/usr/sbin/nfsstat
/usr/sbin/rpc.gssd
/usr/sbin/rpc.idmapd
/usr/sbin/rpc.mountd
/usr/sbin/rpc.nfsd
/usr/sbin/rpc.svcgssd
/usr/sbin/rpcdebug
/usr/sbin/showmount
/usr/sbin/sm-notify
/usr/sbin/start-statd

其中以"rpc."開頭的程式都是rpc service，分別實現不同的功能，啟動它們時每個都需要向rpcbind進行登記註冊。

[root@xuexi ~]# systemctl start nfs.service

[root@xuexi ~]# rpcinfo -p localhost
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  56229  status
    100024    1   tcp  57226  status
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  48609  nlockmgr
    100021    3   udp  48609  nlockmgr
    100021    4   udp  48609  nlockmgr
    100021    1   tcp  50915  nlockmgr
    100021    3   tcp  50915  nlockmgr
    100021    4   tcp  50915  nlockmgr

可以看到，每個program都啟動了不同版本的功能。其中nfs program為rpc.nfsd對應的program，為nfs服務的主進程，埠號為2049。mountd對應的program為rpc.mountd，它為客戶端的mount和umount命令提供服務，即掛載和卸載NFS文件系統時會聯繫mountd服務，由mountd維護相關掛載信息。nlockmgr對應的program為rpc.statd，用於維護文件鎖和文件委托相關功能，在NFSv4以前，稱之為NSM(network status manager)。nfs_acl和status，顯而易見是訪問控制列表和狀態信息維護的program。

再看看啟動的相關進程信息。

[root@xuexi ~]# ps aux | grep -E "[n]fs|[r]pc"
root        748  0.0  0.0      0     0 ?        S<   Jul26   0:00 [rpciod]
rpc        6127  0.0  0.0  64908  1448 ?        Ss   Jul26   0:00 /sbin/rpcbind -w
rpcuser    6128  0.0  0.0  46608  1836 ?        Ss   Jul26   0:00 /usr/sbin/rpc.statd --no-notify
root       6242  0.0  0.0      0     0 ?        S<   Jul26   0:00 [nfsiod]
root       6248  0.0  0.0      0     0 ?        S    Jul26   0:00 [nfsv4.0-svc]
root      17128  0.0  0.0  44860   976 ?        Ss   02:49   0:00 /usr/sbin/rpc.mountd
root      17129  0.0  0.0  21372   420 ?        Ss   02:49   0:00 /usr/sbin/rpc.idmapd
root      17134  0.0  0.0      0     0 ?        S<   02:49   0:00 [nfsd4]
root      17135  0.0  0.0      0     0 ?        S<   02:49   0:00 [nfsd4_callbacks]
root      17141  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17142  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17143  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17144  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17145  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17146  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17147  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17148  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]

其中有一項/usr/sbin/rpc.idmapd進程，該進程是提供服務端的uid/gid <==> username/groupname的映射翻譯服務。客戶端的uid/gid <==> username/groupname的映射翻譯服務則由"nfsidmap"工具實現，詳細說明見下文。

1.4 配置導出目錄和掛載使用

1.4.1 配置nfs導出目錄

在將服務端的目錄共用(share)或者說導出(export)給客戶端之前，需要先配置好要導出的目錄。比如何人可訪問該目錄，該目錄是否可寫，以何人身份訪問導出目錄等。

配置導出目錄的配置文件為/etc/exports或/etc/exports.d/*.exports文件，在nfs服務啟動時，會自動載入這些配置文件中的所有導出項。以下是導出示例：

/www    172.16.0.0/16(rw,async,no_root_squash)

其中/www是導出目錄，即共用給客戶端的目錄；172.16.0.0/16是訪問控制列表ACL，只有該網段的客戶端主機才能訪問該導出目錄，即掛載該導出目錄；緊跟在主機列表後的括弧及括弧中的內容定義的是該導出目錄對該主機的導出選項，例如(rw,async,no_root_squash)表示客戶端掛載/www後，該目錄可讀寫、非同步、可保留root用戶的許可權，具體的導出選項稍後列出。

以下是可接收的幾種導出方式：

/www1    (rw,async,no_root_squash)  # 導出給所有主機，此時稱為導出給world
/www2    172.16.1.1(rw,async)       # 僅導出給單台主機172.16.1.1
/www3    172.16.0.0/16(rw,async) 192.168.10.3(rw,no_root_squash)   # 導出給網段172.16.0.0/16，還導出給單台
                                                                   # 主機192.168.10.3，且它們的導出選項不同
/www4    www.a.com(rw,async)        # 導出給單台主機www.a.com主機，但要求能解析該主機名
/www     *.b.com(rw,async)          # 導出給b.com下的所有主機，要求能解析對應主機名

以下是常用的一些導出選項說明，更多的導出選項見man exports：常見的預設項是：ro,sync,root_squash,no_all_squash,wdelay。

對於root用戶，將取(no_)root_squash和(no_)all_squash的交集。例如，no_root_squash和all_squash同時設置時，root仍被壓縮，root_squash和no_all_squash同時設置時，root也被壓縮。

有些導出選項需要配合其他設置。例如，導出選項設置為rw，但如果目錄本身沒有w許可權，或者mount時指定了ro掛載選項，則同樣不允許寫操作。

至於別的導出選項，基本無需去關註。

在配置文件寫好要導出的目錄後，直接重啟nfs服務即可，它會讀取這些配置文件。隨後就可以在客戶端執行mount命令進行掛載。

例如，exports文件內容如下：

/vol/vol0       *(rw,no_root_squash)
/vol/vol2       *(rw,no_root_squash)
/backup/archive *(rw,no_root_squash)

1.4.2 掛載nfs文件系統

然後去客戶端上掛載它們。

[root@xuexi ~]# mount -t nfs 172.16.10.5:/vol/vol0 /mp1
[root@xuexi ~]# mount 172.16.10.5:/vol/vol2 /mp2
[root@xuexi ~]# mount 172.16.10.5:/backup/archive /mp3

掛載時"-t nfs"可以省略，因為對於mount而言，只有掛載nfs文件系統才會寫成host:/path格式。當然，除了mount命令，nfs-utils包還提供了獨立的mount.nfs命令，它其實和"mount -t nfs"命令是一樣的。

mount掛載時可以指定掛載選項，其中包括mount通用掛載選項，如rw/ro，atime/noatime，async/sync，auto/noauto等，也包括針對nfs文件系統的掛載選項。以下列出幾個常見的，更多的內容查看man nfs和man mount。

以下是針對nfs文件系統的掛載選項。其中沒有給出關於緩存選項(ac/noac、cto/nocto、lookupcache)的說明，它們可以直接採用預設值，如果想要瞭解緩存相關內容，可以查看man nfs。

註意三點：

(1).所謂的soft在特定的環境下超時後會導致靜態數據中斷。因此，僅當客戶端響應速度比數據完整性更重要時才使用soft選項。使用基於TCP的NFS(除非顯示指定使用UDP，否則現在總是預設使用TCP)或增加retrans重試次數可以降低使用soft選項帶來的風險。

(2).由於nfs的客戶端掛載後會緩存文件的屬性信息，其中包括各種文件時間戳，所以mount指定時間相關的掛載選項是沒有意義的，它們不會有任何效果，包括atime/noatime，diratime/nodiratime，relatime/norelatime以及strictatime/nostrictatime等。具體可見man nfs中"DATA AND METADATA COHERENCE"段的"File timestamp maintainence"說明，或者見本文末尾的翻譯。

(3).如果是要開機掛載NFS文件系統，方式自然是寫入到/etc/fstab文件或將mount命令放入rc.local文件中。如果是將/etc/fstab中，那麼在系統環境初始化(exec /etc/rc.d/rc.sysinit)的時候會載入fstab中的內容，如果掛載fstab中的文件系統出錯，則會導致系統環境初始化失敗，結果是系統開機失敗。所以，要開機掛載nfs文件系統，則需要在/etc/fstab中加入一個掛載選項"_rnetdev"，防止無法聯繫nfs服務端時導致開機啟動失敗。例如：

172.16.10.5:/www    /mnt    nfs    defaults,_rnetdev    0    0

當導出目錄後，將在/var/lib/nfs/etab文件中寫入一條對應的導出記錄，這是nfs維護的導出表，該表的內容會交給rpc.mountd進程，併在必要的時候(mountd接受到客戶端的mount請求時)，將此導出表中的內容載入到內核中，內核也單獨維護一張導出表。

1.4.3 nfs偽文件系統

服務端導出/vol/vol0、/vol/vol2和/backup/archive後，其中vol0和vol1是連在一個目錄下的，但它們和archive目錄沒有連在一起，nfs採用偽文件系統的方式來橋接這些不連接的導出目錄。橋接的方式是創建那些未導出的連接目錄，如偽vol目錄，偽backup目錄以及頂級的偽根，如下圖所示。

當客戶端掛載後，每次訪問導出目錄時，其實都是通過找到偽文件系統(文件系統都有id，在nfs上偽文件系統的id稱為fsid)並定位到導出目錄的。

1.5 showmount命令

使用showmount命令可以查看某一臺主機的導出目錄情況。因為涉及到rpc請求，所以如果rpc出問題，showmount一樣會傻傻地等待。

主要有3個選項。

showmount [ -ade]  host
-a：以host:dir格式列出客戶端名稱/IP以及所掛載的目錄。但註意該選項是讀取NFS服務端/var/lib/nfs/rmtab文件，
  ：而該文件很多時候並不准確，所以showmount -a的輸出信息很可能並非準確無誤的
-e：顯示NFS服務端所有導出列表。
-d：僅列出已被客戶端掛載的導出目錄。

另外showmount的結果是排序過的，所以和實際的導出目錄順序可能並不一致。

例如：

[root@xuexi ~]# showmount -e 172.16.10.5
Export list for 172.16.10.5:
/backup/archive *
/vol/vol2       *
/vol/vol0       *
/www            172.16.10.4

[root@xuexi ~]# showmount -d 172.16.10.5
Directories on 172.16.10.5:
/backup/archive
/vol/vol0
/vol/vol2

1.6 nfs身份映射

NFS的目的是導出目錄給各客戶端，因此導出目錄中的文件在服務端和客戶端上必然有兩套屬性、許可權集。

例如，服務端導出目錄中某a文件的所有者和所屬組都為A，但在客戶端上不存在A，那麼在客戶端上如何顯示a文件的所有者等屬性。再例如，在客戶端上，以用戶B在導出目錄中創建了一個文件b，如果服務端上沒有用戶B，在服務端上該如何決定文件b的所有者等屬性。

所以，NFS採用uid/gid <==> username/groupname映射的方式解決客戶端和服務端兩套屬性問題。由於服務端只能控制它自己一端的身份映射，所以客戶端也同樣需要身份映射組件。也就是說，服務端和客戶端兩端都需要對導出的所有文件的所有者和所屬組進行映射。

但要註意，服務端的身份映射組件為rpc.idmapd，它以守護進程方式工作。而客戶端使用nfsidmap工具進行身份映射。

服務端映射時以uid/gid為基準，意味著客戶端以身份B(假設對應uid=Xb，gid=Yb)創建的文件或修改了文件的所有者屬性時，在服務端將從/etc/passwd(此處不考慮其他用戶驗證方式)文件中搜索uid=Xb，gid=Yb的用戶，如果能搜索到，則設置該文件的所有者和所屬組為此uid/gid對應的username/groupname，如果搜索不到，則文件所有者和所屬組直接顯示為uid/gid的值。

客戶端映射時以username/groupname為基準，意味著服務端上文件所有者為A時，則在客戶端上搜索A用戶名，如果搜索到，則文件所有者顯示為A，否則都將顯示為nobody。註意，客戶端不涉及任何uid/gid轉換翻譯過程，即使客戶端上A用戶的uid和服務端上A用戶的uid不同，也仍顯示為用戶A。也就是說，客戶端上文件所有者只有兩種結果，要麼和服務端用戶同名，要麼顯示為nobody。

因此考慮一種特殊情況，客戶端上以用戶B(其uid=B1)創建文件，假如服務端上沒有uid=B1的用戶，那麼創建文件時提交給服務端後，在服務端上該文件所有者將顯示為B1(註意它是一個數值)。再返回到客戶端上看，客戶端映射時只簡單映射username，不涉及uid的轉換，因此它認為該文件的所有者為B1(不是uid，而是username)，但客戶端上必然沒有用戶名為B1的用戶(儘管有uid=B1對應的用戶B)，因此在客戶端，此文件所有者將詭異地將顯示為nobody，其詭異之處在於，客戶端上以身份B創建的文件，結果在客戶端上卻顯示為nobody。

綜上考慮，強烈建議客戶端和服務端的用戶身份要統一，且儘量讓各uid、gid能對應上。

1.7 使用exportfs命令導出目錄

除了啟動nfs服務載入配置文件/etc/exports來導出目錄，使用exportfs命令也可以直接導出目錄，它無需載入配置文件/etc/exports，當然exportfs也可以加在/etc/exports文件來導出目錄。實際上，nfs服務啟動腳本中就是使用exportfs命令來導出/etc/exports中內容的。

例如，CentOS 6上/etc/init.d/nfs文件中，導出和卸載導出目錄的命令為：

[root@xuexi ~]# grep exportfs /etc/init.d/nfs  
        [ -x /usr/sbin/exportfs ] || exit 5
        action $"Starting NFS services: " /usr/sbin/exportfs -r
        cnt=`/usr/sbin/exportfs -v | /usr/bin/wc -l`
                action $"Shutting down NFS services: " /usr/sbin/exportfs -au
        /usr/sbin/exportfs -r

在CentOS 7上則如下：

[root@xuexi ~]# grep exportfs /usr/lib/systemd/system/nfs.service      
ExecStartPre=-/usr/sbin/exportfs -r
ExecStopPost=/usr/sbin/exportfs -au
ExecStopPost=/usr/sbin/exportfs -f
ExecReload=-/usr/sbin/exportfs -r

當然，無論如何，nfsd等守護進程是必須已經運行好的。

以下是CentOS 7上exportfs命令的用法。註意， CentOS 7比CentOS 6多一些選項。

-a     導出或卸載所有目錄。
-o options,...
       指定一系列導出選項(如rw,async,root_squash)，這些導出選項在exports(5)的man文檔中有記錄。
-i     忽略/etc/exports和/etc/exports.d目錄下文件。此時只有命令行中給定選項和預設選項會生效。
-r     重新導出所有目錄，並同步修改/var/lib/nfs/etab文件中關於/etc/exports和/etc/exports.d/
       *.exports的信息(即還會重新導出/etc/exports和/etc/exports.d/*等導出配置文件中的項)。該
       選項會移除/var/lib/nfs/etab中已經被刪除和無效的導出項。
-u     卸載(即不再導出)一個或多個導出目錄。
-f     如果/prof/fs/nfsd或/proc/fs/nfs已被掛載，即工作在新模式下，該選項將清空內核中導出表中
       的所有導出項。客戶端下一次請求掛載導出項時會通過rpc.mountd將其添加到內核的導出表中。
-v     輸出詳細信息。
-s     顯示適用於/etc/exports的當前導出目錄列表。

例如：

(1).導出/www目錄給客戶端172.16.10.6。

exportfs 172.16.10.6:/www

(2).導出/www目錄給所有人，並指定導出選項。

exportfs :/www -o rw,no_root_squash

(3).導出exports文件中的內容。

exportfs -a

(4).重新導出所有已導出的目錄。包括exports文件中和exportfs單獨導出的目錄。

exportfs -ar

(5).卸載所有已導出的目錄，包括exports文件中的內容和exportfs單獨導出的內容。即其本質為清空內核維護的導出表。

exportfs -au

(6).只卸載某一個導出目錄。

exportfs -u 172.16.10.6:/www

1.8 深入NFS的方向

本文僅簡單介紹了一些NFS的基本使用方法，但NFS自身其實是很複雜的，想深入也不是一件簡單的事。例如，以下列出了幾個NFS在實現上應該要解決的問題。

(1).多台客戶端掛載同一個導出的目錄後，要同時編輯其中同一個文件時，應該如何處理？這是共用文件更新問題，通用的解決方法是使用文件鎖。

(2).客戶端上對文件內容做出修改後是否要立即同步到服務端上？這是共用文件的數據緩存問題，體現的方式是文件數據是否要在各客戶端上保證一致性。和第一個問題結合起來，就是分散式(集群)文件數據一致性問題。

(3).客戶端或服務端進行了重啟，或者它們出現了故障，亦或者它們之間的網路出現故障後，它們的對端如何知道它已經出現了故障？這是故障通知或重啟通知問題。

(4).出現故障後，正常重啟成功了，那麼如何恢復到故障前狀態？這是故障恢復問題。

(5).如果服務端故障後一直無法恢復，客戶端是否能自動故障轉移到另一臺正常工作的NFS服務節點？這是高可用問題。(NFS版本4(後文將簡寫為NFSv4)可以從自身實現故障轉移，當然使用高可用工具如heartbeat也一樣能實現)

總結起來就幾個關鍵詞：鎖、緩存、數據和緩存一致性、通知和故障恢復。從這些關鍵字中，很自然地會聯想到了集群和分散式文件系統，其實NFS也是一種簡易的分散式文件系統，但沒有像集群或分散式文件系統那樣實現幾乎完美的鎖、緩存一致性等功能。而且NFSv4為了體現其特點和性能，在一些通用問題上採用了與集群、分散式文件系統不同的方式，如使用了文件委托(服務端將文件委托給客戶端，由此實現類似鎖的功能)、鎖或委托的租約等(就像DHCP的IP租約一樣，在租約期內，鎖和委托以及緩存是有效的，租約過期後這些內容都無效)。

由此知，深入NFS其實就是在深入分散式文件系統，由於網上對NFS深入介紹的文章幾乎沒有，所以想深入它並非一件簡單的事。如果有深入學習的想法，可以閱讀NFSv4的RFC3530文檔的前9章。以下是本人的一些man文檔翻譯。

翻譯：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中關於傳輸方法和緩存相關內容的翻譯。

TRANSPORT METHODS
       NFS客戶端是通過RPC向NFS服務端發送請求的。RPC客戶端會自動發現遠程服務端點，處理每請求(per-request)的
       身份驗證，調整當客戶端和服務端之間出現不同位元組位元組序(byte endianness)時的請求參數，並且當請求在網路
       上丟失或被服務端丟棄時重傳請求。rpc請求和響應數據包是通過網路傳輸的。
 
       在大多數情形下，mount(8)命令、NFS客戶端和NFS服務端可以為掛載點自動協商合適的傳輸方式以及數據傳輸時
       的大小。但在某些情況下，需要使用mount選項顯式指定這些設置。
 
       對於的傳統NFS，NFS客戶端只使用UDP傳輸請求給服務端。儘管實現方式很簡單，但基於UDP的NFS有許多限制，在
       一些通用部署環境下，這些限制項會限制平滑運行的能力，還會限制性能。即使是UDP丟包率極小的情況，也將
       導致整個NFS請求丟失；因此，重傳的超時時間一般都是亞秒級的，這樣可以讓客戶端從請求丟失中快速恢復，但
       即使如此，這可能會導致無關的網路阻塞以及服務端負載加重。
 
       但是在專門設置了網路MTU值是相對於NFS的輸出傳輸大小時(例如在網路環境下啟用了巨型乙太網幀)(註：相對的
       意思，例如它們成比例關係)，UDP是非常高效的。在這種環境下，建議修剪rsize和wsize，以便讓每個NFS的讀或
       寫請求都能容納在幾個網路幀(甚至單個幀)中。這會降低由於單個MTU大小的網路幀丟失而導致整個讀或寫請求丟
       失的概率。
      
       (譯者註：UDP是NFSv2和NFSv3所支持的，NFSv4使用TCP，所以以上兩段不用考慮)
 
       現代NFS都預設採用TCP傳輸協議。在幾乎所有可想到的網路環境下，TCP都表現良好，且提供了非常好的保證，防
       止因為網路不可靠而引起數據損壞。但使用TCP傳輸協議，基本上都會考慮設置相關防火牆。
 
       在正常環境下，網路丟包的頻率比NFS服務丟包的頻率要高的多。因此，沒有必要為基於TCP的NFS設置極短的重傳
       超時時間。一般基於TCP的NFS的超時時間設置在1分鐘和10分鐘之間。當客戶端耗盡了重傳次數(選項retrans的值)，
       它將假定發生了網路分裂，並嘗試以新的套接字重新連接服務端。由於TCP自身使得網路傳輸的數據是可靠的，所
       以，可以安全地使用處在預設值和客戶端服務端同時支持的最大值之間的rszie和wsize，而不再依賴於網路MTU大小。
 
DATA AND METADATA COHERENCE
       現在有些集群文件系統為客戶端之間提供了非常完美的緩存一致性功能，但對於NFS客戶端來說，實現完美的緩
       存一致性是非常昂貴的，特別是大型區域網絡環境。因此，NFS提供了稍微薄弱一點的緩存一致性功能，以滿足
       大多數文件共用需求。
 
   Close-to-open cache consistency
       一般情況下，文件共用是完全序列化的。首先客戶端A打開一個文件，寫入一些數據，然後關閉文件然後客戶端B
       打開同一個文件，並讀取到這些修改後的數據。
      
       當應用程式打開一個存儲在NFSv3服務端上的文件時，NFS客戶端檢查文件在服務端上是否存在，並通過是否發送
       GETATTR或ACCESS請求判斷文件是否允許被打開。NFS客戶端發送這些請求時，不會考慮已緩存文件屬性是否是新
       鮮有效的。
 
       當應用程式關閉文件，NFS客戶端立即將已做的修改寫入到文件中，以便下一個打開者可以看到所做的改變。這
       也給了NFS客戶端一個機會，使得它可以通過文件關閉時的返回狀態碼嚮應用程式報告錯誤。
 
       在打開文件時以及關閉文件刷入數據時的檢查行為被稱為close-to-open緩存一致性，或簡稱為CTO。可以通過使
       用nocto選項來禁用整個掛載點的CTO。
      
       (譯者註：NFS關閉文件時，客戶端會將所做的修改刷入到文件中，然後發送GETATTR請求以確保該文件的屬性緩存
       已被更新。之後其他的打開者打開文件時會發送GETATTR請求，根據文件的屬性緩存可以判斷文件是否被打開並做
       了修改。這可以避免緩存無效)
 
   Weak cache consistency
       客戶端的數據緩存仍有幾乎包含過期數據。NFSv3協議引入了"weak cache consistency"(WCC)，它提供了一種在單
       個文件被請求之前和之後有效地檢查文件屬性的方式。這有助於客戶端識別出由其他客戶端對此文件做出的改變。
 
       當某客戶端使用了併發操作，使得同一文件在同一時間做出了多次更新(例如，後臺非同步寫入)，它仍將難以判斷
       是該客戶端的更新操作修改了此文件還是其他客戶端的更新操作修改了文件。
 
   Attribute caching
       使用noac掛載選項可以讓多客戶端之間實現屬性緩存一致性。幾乎每個文件系統的操作都會檢查文件的屬性信息。
       客戶端自身會保留屬性緩存一段時間以減少網路和服務端的負載。當noac生效時，客戶端的文件屬性緩存就會被
       禁用，因此每個會檢查文件屬性的操作都被強制返回到服務端上來操作文件，這表示客戶端以犧牲網路資源為代
       價來快速查看文件發生的變化。
 
       不要混淆noac選項和"no data caching"。noac掛載選項阻止客戶端緩存文件的元數據，但仍然可能會緩存非元數
       據的其他數據。
 
       NFS協議設計的目的不是為了支持真正完美的集群文件系統緩存一致性。如果要達到客戶端之間緩存數據的絕對
       一致，那麼應該使用文件鎖的方式。
 
   File timestamp maintainence
       NFS服務端負責管理文件和目錄的時間戳(atime,ctime,mtime)。當服務端文件被訪問或被更新，文件的時間戳也會
       像本地文件系統那樣改變。
 
       NFS客戶端緩存的文件屬性中包括了時間戳屬性。當NFS客戶端檢索NFS服務端文件屬性時，客戶端文件的時間戳會
       更新。因此，在NFS服務端的時間戳更新後顯示在NFS客戶端之前可能會有一些延遲。
 
       為了遵守POSIX文件系統標準，Linux NFS客戶端需要依賴於NFS服務端來保持文件的mtime和ctime時間戳最新狀態。
       實現方式是先讓客戶端將改變的數據刷入到服務端，然後再輸出文件的mtime。
 
       然而，Linux客戶端可以很輕鬆地處理atime的更新。NFS客戶端可以通過緩存數據來保持良好的性能，但這意味著
       客戶端應用程式讀取文件(會更新atime)時，不會反映到服務端，但實際上服務端的atime已經修改了。
 
       由於文件屬性緩存行為，Linux NFS客戶端mount時不支持一般的atime相關的掛載選項。
 
       特別是mount時指定了atime/noatime，diratime/nodiratime，relatime/norelatime以及strictatime/nostrictatime
       掛載選項，實際上它們沒有任何效果。
 
   Directory entry caching
       Linux NFS客戶端緩存所有NFS LOOKUP請求的結果。如果所請求目錄項在服務端上存在，則查詢的結果稱為正查詢
       結果。如果請求的目錄在服務端上不存在(服務端將返回ENOENT)，則查詢的結果稱為負查詢結果。
 
       為了探測目錄項是否添加到NFS服務端或從其上移除了，Linux NFS客戶端會監控目錄的mtime。如果客戶端監測到
       目錄的mtime發生了改變，客戶端將丟棄該目錄相關的所有LOOKUP緩存結果。由於目錄的mtime是一種緩存屬性，因
       此