?? rfc1094.txt
字號:
組織:中國互動出版網(http://www.china-pub.com/)
RFC文檔中文翻譯計劃(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:ouyang@china-pub.com
譯者:馬東輝(eaststone ma_donghui@263.net)
譯文發布時間:2001-4-4
版權:本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載,但必須保留本文檔的翻譯及版權信息。
Network Working Group Sun Microsystems, Inc.
Request for Comments: 1094 March 1989
RFC1094 網絡文件系統協議
(RFC1094 NFS: Network File System Protocol Specification)
本備忘錄狀態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
版權聲明
Copyright (C) The Internet Society (1999). All Rights Reserved.
摘要:
網絡文件系統可以使訪問遠程機上的目錄和文件象在本地機上一樣方便。本文就是介紹網絡文件系統協議規范的中文版。
目錄
1. 簡介 2
1.1 遠程過程調用 2
1.2 外部數據描述 2
1.3 無狀態服務器 3
2. NFS 協議定義 3
2.1 文件系統模型 3
2.2 服務器過程 4
2.3 基本數據類型 12
3. NFS實現中的問題 18
3.1 服務器/客戶端 的關系 18
3.2 路徑名解析 18
3.3 許可問題 19
3.4 RPC信息 19
3.4 XDR結構的尺寸 20
3.6 設置RPC的參數 20
附錄A 安裝協議定義 21
A.1. 簡介 21
A.2 RPC信息 21
A.3 XDR結構的尺寸 21
A.4 基本數據類型 22
A.5. 服務器過程 23
作者地址 25
1. 簡介
Sun的網絡文件系統(NFS)協議提供了對網絡中的共享文件進行透明的遠程訪問。NFS協議被設計為適合于不同的機器,操作系統,網絡體系和傳輸協議。這種廣泛的適應性是通過使用建立在外部數據描述(XDR)之上的遠程過程調用(RPC)原語得到的。此協議的實現已經存在于從個人電腦到超級電腦等不同種類的機器之上,。
對安裝協議的支持允許服務器分發遠程訪問優先級給一個受限制的客戶集。它執行了操作系統特定的功能,以允許把遠程目錄樹鏈接在本地的文件系統上。
1.1 遠程過程調用
Sun的遠程過程調用規范提供了一個面向過程的遠程服務的接口。.每一個服務器都提供了一個包含著一組過程的“程序”。NFS就是一種這樣的程序。主機地址,程序號和過程號的組合指定了一個遠程過程。NFS的一個目標就是不需要它的下層提供任何特定級別的可靠性。所以,它潛在地可以被使用在許多下層的傳輸層協議之上,甚至在另一個遠程過程調用實現之上。為了便于討論,本文檔的剩余部分假定NFS實現在Sun的RPC上層。
1.2 外部數據描述
外部數據描述(XDR)標準提供了一個在網絡上描述數據類型的公用方法。NFS協議規范就是使用RPC數據描述語言撰寫的。要想獲得更多的信息,請參見RFC 1014 "XDR:外部數據描述標準"。盡管存在自動化的RPC/XDR編譯器可以產生服務器和客戶端的“樁”(stubs)。NFS也不需要使用它們。任何提供相同功能的軟件都可以使用,如果編碼完全相同的話,它也可以與其它的NFS實現進行互操作。
1.3 無狀態服務器
NFS協議被希望盡可能無狀態。也就是說,服務器應該不必保持關于它的客戶端的任何協議狀態信息,這是為了功能正確。在失敗的事件發生的時候,無狀態服務器比有狀態服務器有著明顯的優點。在無狀態服務器中,客戶端僅僅需要重發請求直到服務器響應;客戶端甚至不需要知道服務器已經崩潰或者是網絡臨時故障。而有狀態服務器的客戶端要么需要檢測服務器失敗,并且在服務器恢復的時候重建服務器狀態,要么使客戶端操作失敗。
這可能聽起來不象是一個重要的問題,但是它在一些意想不到的情況下影響著協議。我們認為只要能寫一個非常簡易的服務器,不需要在崩潰后花費昂貴的代價恢復,即使在協議中多一些額外的復雜性也是值得的。注意:即使使用號稱“可靠”的傳輸協議TCP的時候,客戶端也必須能夠處理當它們超時的時候再次打開連接所產生的服務的中斷。因此,無狀態協議實際上可以使這個實現簡化。
另一方面,NFS處理文件、目錄這樣本身就有狀態的對象。如果文件不保持它的內容沒被接觸過會有什么好處呢?這樣做的目的就是在協議本身不引入任何額外的狀態。固有的狀態操作,諸如文件或者記錄鎖定和遠程執行都作為分開的服務實現,在此不討論。
簡化恢復的基本方法就是盡可能的采取“冪等”操作(為了它們有被重復的潛力)。這個協議版本中的一些操作并不能達到這個目的;幸運的是,大多數操作(例如Read 和Write)是冪等的。而且,多數服務器失敗發生在操作之間,而不是發生在收到操作和響應之間。最后,盡管實際上服務器的失敗可能很少,但是在復雜的網絡中,任何網絡,路由器或者網橋的失敗與服務器的失敗都是很難區分的。
2. NFS 協議定義
服務器隨著時間改變,服務器使用的協議也一樣。RPC對每一個RPC請求都提供了一個版本號。RFC已經定義了NFS協議的兩個版本。即使在第二版中,也有少部分過時的過程和參數,這將在以后的版本中被刪除。NFS協議第三版的RPC當前正在準備之中。(譯者注:這是相對此RFC文檔發布的時間來講的,此文檔發表于1989,3)
2.1 文件系統模型
NFS假定文件系統是分層次的,除了最底層是文件,其它層次都是目錄。在目錄中的每一個條目(文件,目錄,設備等)都有一個字符串名。不同的操作系統可能在目錄樹的深度或者使用的名字上有所限制,就象用不同的語義來描述“路徑名”,它是在名字中把所有組成部分(目錄和文件名)串聯起來。一個“文件系統”就是在一個單一的服務器上(通常是一個磁盤或者物理分區)有一個指定的“根”的樹。一些操作系統提供了“安裝”操作使所有的文件系統出現在一棵單一的樹上。而其它的操作系統保持著一個文件系統“森林”。文件是由無解釋字節組成的無結構流。第三版的NFS使用更普遍的文件系統模型。
NFS一次只查詢路徑名中的一個組成部分。為什么不一次就得到整個路徑名,返回一個文件句柄呢?這里有一些不這樣做的原因。首先,路徑名需要在路徑的組成部分之間有分隔符。不同的操作系統使用不同的分隔符。我們可以定義一種網絡上標準的路徑表示法,但是每一個路徑名在每一個終點上將必須進行語法分析和轉換。其它的問題在第三節(NFS實現中的問題)里討論。
盡管文件和目錄在許多方面是相似的對象,但是讀目錄和讀文件也需要不同的過程。這里提供了描述目錄的網絡標準格式。使用象上面相同的參數來確定一個過程,此過程在每次調用的時候只返回一個目錄項。這種方法產生的問題就是效率不高。目錄包含著許多目錄項,遠程調用要返回每一項將是非常緩慢的。
2.2 服務器過程
這個協議被定義為一組過程,這組過程具有用RPC語言(XDR語言在程序,版本,過程聲明方面的擴展)定義的參數和結果。每一個過程功能的簡要描述都應該提供足夠允許實現的信息。2.3節詳細地描述了基本數據類型。
在NFS協議中的所有過程都假定是同步的。當一個過程返回給客戶端,客戶可以假定此操作已經完成,與請求相關的任何數據現在在一個穩定的存儲上。例如,客戶端的WRITE請求可能導致服務器更新數據塊,文件系統信息塊(比如間接塊),和文件屬性信息(大小和修改時間)。當WRITE返回給客戶端,客戶端假定這個寫操作是可靠的。甚至在服務器崩潰的情況下,它也能丟棄這些已經寫的數據。這就是服務器無狀態的一個非常重要的部分。 如果服務器等待來自遠程請求的刷新數據,客戶端必須保存這些請求, 以便在服務器崩潰的情況下再次發送這些請求。
/*
* 遠程文件服務程序
*/
program NFS_PROGRAM {
version NFS_VERSION {
void NFSPROC_NULL(void) = 0;
attrstat NFSPROC_GETATTR(fhandle) = 1;
attrstat NFSPROC_SETATTR(sattrargs) = 2;
void NFSPROC_ROOT(void) = 3;
diropres NFSPROC_LOOKUP(diropargs) = 4;
readlinkres NFSPROC_READLINK(fhandle) = 5;
readres NFSPROC_READ(readargs) = 6;
void NFSPROC_WRITECACHE(void) = 7;
attrstat NFSPROC_WRITE(writeargs) = 8;
diropres NFSPROC_CREATE(createargs) = 9;
stat NFSPROC_REMOVE(diropargs) = 10;
stat NFSPROC_RENAME(renameargs) = 11;
stat NFSPROC_LINK(linkargs) = 12;
stat NFSPROC_SYMLINK(symlinkargs) = 13;
diropres NFSPROC_MKDIR(createargs) = 14;
stat NFSPROC_RMDIR(diropargs) = 15;
readdirres NFSPROC_READDIR(readdirargs) = 16;
statfsres NFSPROC_STATFS(fhandle) = 17;
} = 2;
} = 100003;
2.2.1 不做工作
void NFSPROC_NULL(void) = 0;
這個過程不做工作,在所有RPC服務中它可以用來允許服務器響應測試和定時。
2.2.2 獲得文件屬性
attrstat NFSPROC_GETATTR (fhandle) = 1;
如果響應狀態是 NFS_OK,那么響應屬性包含由輸入fhandle指定的文件的屬性。
2.2.3. 設置文件屬性
struct sattrargs {
fhandle file;
sattr attributes;
};
attrstat NFSPROC_SETATTR (sattrargs) = 2;
"attributes"值參數包含著一些字段,這些字段要么是 -1,要么是 "file"的文件屬性的一個新值。如果響應狀態是NFS_OK,那么響應屬性在"SETATTR"操作完成之后具有文件的屬性。
注意: -1指示在 "attributes"中一個沒有使用的字段,在協議的下一版本將修改。
2.2.4 獲得文件系統的根
void NFSPROC_ROOT(void) = 3;
已經過時。這個過程不再使用,因為找到一個文件系統的根文件句柄需要在客戶端和服務器之間移動路徑名。為了正確的做到這一點,我們必須定義一個路徑名網絡標準描述。查詢根文件句柄已經由MNTPROC_MNT過程來實現。(詳細情況請參見附錄A,“安裝協議定義”)
2.2.5. 查詢文件名
diropres NFSPROC_LOOKUP(diropargs) = 4;
如果響應"status"是NFS_OK,響應 "file"和響應 "attributes"是參數 "dir"給定的目錄中的文件名的文件句柄和屬性。
2.2.6 從符號鏈接讀
union readlinkres switch (stat status) {
case NFS_OK:
path data;
default:
void;
};
readlinkres NFSPROC_READLINK(fhandle) = 5;
如果"status"的值是NFS_OK,響應 "data"是fhandle參數引用的文件的符號鏈接中的數據。
注意:因為NFS總是在客戶端解析路徑名,如果在不同的客戶端或者服務器上使用不同的語義,那么在一個符號鏈接中的路徑名可能有不同的含義(或者無意義)。
2.2.7 從文件中讀
struct readargs {
fhandle file;
unsigned offset;
unsigned count;
unsigned totalcount;
};
union readres switch (stat status) {
case NFS_OK:
fattr attributes;
nfsdata data;
default:
void;
};
readres NFSPROC_READ(readargs) = 6;
在由 "file"給出的文件中,從“offset”字節偏移開始返回 "count"個字節的 "data"。 這個文件的第一個字節是偏移量0。在讀操作發生后,文件屬性從 "attributes"中返回。
注意:參數 "totalcount"沒有使用,在協議的下一修訂版中將刪除。
2.2.8 寫到緩沖區
void NFSPROC_WRITECACHE(void) = 7;
將在協議的下一修訂版中使用。
2.2.9 寫到文件
struct writeargs {
fhandle file;
unsigned beginoffset;
unsigned offset;
unsigned totalcount;
nfsdata data;
};
attrstat NFSPROC_WRITE(writeargs) = 8;
從 "file"開頭偏移的 "offset"字節處開始寫數據 "data"。文件的第一個字節是在偏移0的位置。如果響應狀態 "status"是NFS_OK,那么在寫操作完成后響應屬性 "attributes"中包含著文件的屬性。寫操作是原子的,從這次"WRITE"中寫入的數據不會與客戶端的另一次"WRITE"寫入的數據混合在一起。
注意:參數"beginoffset"和"totalcount"被忽略,在協議的下一修訂版中將被刪除。
2.2.10 創建文件
struct createargs {
diropargs where;
sattr attributes;
};
diropres NFSPROC_CREATE(createargs) = 9;
文件"name"創建在由 "dir"指定的目錄中。新文件的初始屬性由"attributes"決定。 NFS_OK的響應狀態表明這個文件被創建。響應"file"和響應"attributes"是這個文件的文件句柄和屬性。任何其它的響應狀態 "status"都意味著此操作失敗,沒有文件被創建。
注意: 這個例程可以傳遞一個排它的創建標志,意味著“僅在文件不存在的時候創建這個文件”。
2.2.11 刪除文件
stat NFSPROC_REMOVE(diropargs) = 10;
文件 "name"從 "dir"確定的目錄中刪除。NFS_OK的響應意味著這個目錄項被刪除。
注意:可能不是冪等地操作。
2.2.12 重命名文件
struct renameargs {
diropargs from;
diropargs to;
};
stat NFSPROC_RENAME(renameargs) = 11;
在"from.dir"目錄中的"from.name"文件被更名為"to.dir"目錄中的文件名"to.name"。如果響應是NFS_OK,文件被更名。更名操作在服務器上是一個原子操作;它不能在執行中被中斷。
注意:可能不是冪等地操作。
2.2.13 創建文件鏈接
過程12,版本2。
struct linkargs {
fhandle from;
diropargs to;
};
stat NFSPROC_LINK(linkargs) = 12;
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -