RFC文檔

• RFC3530: NFS 4
• RFC5661: NFS 4.1
• RFC4506: XDR
• RFC5531: RPC

1. Introduction

1.6 General Definitions

• Client: 訪問Server的實體持痰，Client由client owner唯一代表漠烧。
• Client ID: 64-bit ID,用戶的verifier和owner的shorthand引用哮独。
• Client Owner: 是Client的唯一代表，client重啟后此值也不變鸵赫。
• Lock: byte-range locks, share reservations,delegations, or layouts unless specifically stated otherwise.
• Server Owner: major identifier and a minor identifier。major identifier相同認為是同一個Sever，major identifier和minor identifier都相同触创，代表是同一個session瘟滨。
• Stateid: A stateid is a 128-bit quantity returned by a server that uniquely defines the open and locking states provided by the server for a specific open-owner or lock-owner/open-owner pair for a specific file and type of lock.
• Verifier: 64bit的id候醒，client傳給server的，server可以判讀client是否重啟了杂瘸。

1.8 Differences from NFSv4.0

• Implementation of the sessions model
• Parallel access to data
• Addition of the RECLAIM_COMPLETE operation to better structure the lock reclamation process
• Enhanced delegation support as follows
• 支持微軟的ACL

2. Core Infrastructure

2.4 Client Identifiers and Client Owners

Clientid是64-bit ID,由server分配火焰。Client和Sever重啟，都會導致Clientid變化胧沫。一個Session對應一個clientid昌简。
大部分操作必須在這兩個操作之后：

• EXCHANGE_ID: 將client_owner4轉換成64bit的clientid ,作為client_owner的shorthand
• CREATE_SESSION: 根據(jù)EXCHANGE_ID傳進來的client_owner4進行confirm
  它們取代了NFS4的SETCLIENTID和SETCLIENTID_CONFIRM。

struct client_owner4 {
        verifier4       co_verifier;//client重啟后會變化
        opaque          co_ownerid<NFS4_OPAQUE_LIMIT>;//client重啟后不會變化
};

2.5 Server Owners

類似Client Owners绒怨，但沒有server id的概念纯赎。

struct server_owner4 {
    uint64_t       so_minor_id;
    opaque         so_major_id<NFS4_OPAQUE_LIMIT>;
};

此信息是EXCHANGE_ID返回。相同的sever返回的so_major_id相同南蹂。如果so_minor_id也相同犬金，the session can be shared across both connections。

2.10 Session

2.10.1 Motivation and Overview

以前的NFS的問題

• 缺少EOS (Exactly Once Semantics)
• Limited callback support
• Limited trunking over multiple network paths
• Requiring machine credentials for fully secure operation
  NFS4.1解決了
• EOS is enabled by a reply cache with a bounded size
• Callback的支持
• Session可以有多個connection
  Session的state和connection無關六剥。Client可以有多個session晚顷。

2.10.2 NFSv4 Integration

2.10.2.1 SEQUENCE and CB_SEQUENCE

SEQUENCE必須是COMPOUND RPC中的第一個操作。

2.10.2.2 Client ID and Session Association

每次session的操作疗疟，都會renew lease该默。state和client相關聯(lián)，并不和session關聯(lián)策彤。Session A用來獲取delegation,而recall delegation可以發(fā)生在Session B上(只要它們的clientid相同)栓袖。

2.10.3 Channels

Session有兩種channel：
fore channel: Client => Server
back channel: Server => Client(可以沒有)

2.10.3.1 Association of Connections, Channels, and Sessions

每個channel和0個或多個connection聯(lián)系匣摘。每個connection和1個或2個channel聯(lián)系。這個個數(shù)是由CREATE_SESSION和BIND_CONN_TO_SESSION操作時確定的裹刮。connection和session的聯(lián)系并不排他音榜，即其他connection也可以和同一個Session聯(lián)系。

2.10.4 Server Scope

EXCHANGE_ID返回的eir_server_scope為Server Scope,如果兩個server的Server Scope的相同捧弃，代表這兩個server具有相同的scope赠叼，即下列的值有相同含義:

• Filehandle values
• Session ID values
• Client ID values
• State ID values
• Server owner values

2.10.5 Trunking

Trunking使用multiple connections來增大吞吐。NFS4.1支持session trunking和client ID trunking违霞。
session trunking本質上是多個connection梅割，關聯(lián)到同一個session。如果兩個連接的目標地址一樣葛家，就必須支持session trunking户辞。
client ID trunking是將多個相同clint ID的session關聯(lián)起來。如果兩個Server返回相同的major server owner和server scope癞谒，它們使用相同的lock state management ,這是使用client ID trunking的前提底燎。

2.10.6 Exactly Once Semantics

在COMPOUND和CB_COMPOUND請求中，第一個操作SEQUENCE或CB_SEQUENCE弹砚，一定只運行一次双仍。需要了解以下概念：

• Non-idempotent requests.如rename操作。
• Idempotent modifying requests.如write操作桌吃。
• Idempotent non-modifying requests.如SEQUENCE, PUTFH, READLINK操作朱沃。
  不EOS會帶來以下問題:

1. Client發(fā)送Write A到Server
2. 由于network partition，response沒有返回
3. Client重新發(fā)送Write A到Server
4. Client的第二次的Write A得到response
5. Client發(fā)送Write B(這個操作和第一次的Write A會產生overlap)
   真正意義上的EOS是很難實現(xiàn)的茅诱，它需要永不重啟逗物，保存reply cache。

2.10.6.1 Slot Identifiers and Reply Cache

RPC的XID(transaction ID)不適合跟蹤請求是否請求過瑟俭。
NFSv4.1 reply cache使用slot id,取值范圍是0~N,N的數(shù)值取決于CREATE_SESSION的ca_maxrequests返回值翎卓。也可以在后面的SEQUENCE和CB_SEQUENCE操作中調節(jié)。在同一個session中摆寄，可以ca_maxrequests個并發(fā)請求(決定著在這個Session并發(fā)的最大數(shù)量)失暴，每個請求從slot table中分配一個slotid，這個slotid沒有對應的outstanding request微饥。
Client的請求帶著三個值:session id,slot id,sequence

1. 如果client的seq等于server的seq+1逗扒，說明是新請求，處理并返回欠橘。
2. 如果client的seq等于server的seq矩肩，說明是剛剛處理過的請求，直接從cached reply里的結果返回简软。
3. 如果client的seq小于server的seq蛮拔，說明是太老的請求，返回NFS4ERR_SEQ_MISORDERED
4. 如果client的seq大于server的seq+1痹升，返回NFS4ERR_SEQ_MISORDERED

2.10.11 Session Mechanics - Steady State

2.10.13 Session Mechanics - Recovery

2.10.14 Parallel NFS and Sessions

4. Filehandles

4.1 Obtaining the First Filehandle

4.1.1 Root Filehandle

PUTROOTFH操作將root filehandle設置為current filehandle建炫。PUTROOTFH操作之后，就可以用LOOKUP操作遍歷所有目錄/文件疼蛾。

4.1.2 Public Filehandle

用戶使用PUTPUBFH操作使用public filehandle

4.2 Filehandle Types

4.2.1 General Properties of a Filehandle

4.2.2 Persistent Filehandle

固定值作為filehandle肛跌。即便server重啟了，相同文件必須使用以前一樣的filehandle代表察郁。如果這個filehandle代表的文件不存在了衍慎，應該返回NFS4ERR_STALE。

4.2.3 Volatile Filehandle

特別適用于pseudo file systems皮钠。
fh_expire_type屬性：

• FH4_PERSISTENT
• FH4_VOLATILE_ANY

4.4 Client Recovery from Filehandle Expiration

client需要從NFS4ERR_FHEXPIRED錯誤碼開始恢復稳捆。

5 File Attributes

分為三類：REQUIRED, RECOMMENDED, and named。
對于REQUIRED和RECOMMENDED屬性麦轰，設置相應的bit在請求里乔夯。
Named屬性使用OPENATTR操作。這個屬性和NFS協(xié)議無關款侵，而是作為應用程序的特殊需求末荐。

8. State Management

Lock的引入，導致了nfs有狀態(tài)新锈，Sever端維護這個狀態(tài)甲脏。用一個128bit的stateid描述 ，它可能代表一個open file, 一組range lock,a recallable delegation

8.1 Client and Session ID

在執(zhí)行open, byte-range lock,delegation和過得layout之前, Client需要創(chuàng)建一個clientid和若干個sessionid妹笆。這個sessionid和clientid有所聯(lián)系块请。sessionid作為client的一個 shorthand reference。對于一些lock來說拳缠，client還代表被稱作owner的實體负乡。對于其他lock來說(delegation,layout)，并沒有這樣的中間的實體對應脊凰。

8.2 Stateid Definition

當Server grant了某種lock,他就會返回一個stateid來表示這些lock抖棘。由不同open owner打開同一個文件，會對應同一個stateid狸涌。
給定stateid切省，Sever可以獲得聯(lián)系的的state-owner或state-owners(這個上下文是open-owner/lock-owner pair)，還能獲得filehandle帕胆。
stateid是針對client范圍的的朝捆，server對于不同的client會分配相同的stateid。(stateid+clientid定位這個lock資源)

8.2.1 Stateid Types

• Stateids可以表示opens of files.在這個上下文中懒豹，stateid表示(clientid,open-owner,filehandle)三元組芙盘。
• Stateids可以表示byte-range locks.
• Stateids可以表示file delegations.
• Stateids可以表示directory delegations.
• Stateids可以表示layouts

8.2.2 Stateid Structure

struct stateid4 {
    uint32_t seqid;
    char other[12]; //ganesha定義和RFC不一致?
};

96-bit other field:識別具體的lock
32-bit seqid sequence:狀態(tài)變化是自增驯用，初始值為1
除了layout stateids，client會將seqid設置為0儒老，目的是讓server用其最高版本蝴乔。也可以傳入非0值，讓Server判斷是否正確驮樊。

8.2.3 Special Stateids

otherfield全零或者全1薇正。

• other and seqid 全零。
• other and seqid 全1囚衔。stateid代表special READ bypass挖腰。對于讀操作，即便上鎖也可以bypass练湿。

8.2.4 Stateid Lifetime and Validation

n/a

8.2.5 Stateid Use for I/O Operations

N/A

8.2.6 Stateid Use for SETATTR Operations

N/A

8.3 Lease Renewal

N/A

8.4 Crash Recovery

Sever和Client都需要知道對方是否crash猴仑。對于Server重啟前后，Client看到的數(shù)據(jù)需要一致肥哎。

8.4.1 Client Failure and Recovery

Client的lease過期后宁脊，Sever釋放相關的lock。
為了縮短client因restart導致的delay,lock操作和client_owner4中的verifier關聯(lián)贤姆。對于EXCHANGE_ID操作榆苞， Sever返回clientid。Clientg確認clientid后霞捡，進一步建立Session坐漏。Client重啟后，verifier會變碧信。Server會比較這個verifier和lock關聯(lián)的verifier赊琳，如果不一致說明client重啟。

8.4.2 Server Failure and Recovery

Server在grace period恢復lock的狀態(tài)砰碴。Client可以通過這些辦法判斷丟掉lock

• SEQUENCE和其他operation,返回NFS4ERR_BADSESSION,代表session被Destory,但clientid還有效躏筏。此時可以CREATE_SESSION重建Session。如果CREATE_SESSION返回NFS4ERR_STALE_CLIENTID呈枉，則表明clientid失效趁尼。
• SEQUENCE和其他operation,返回NFS4ERR_DEADSESSION，代表session已經(jīng)不可用猖辫。CREATE_SESSION重建session酥泞，如果CREATE_SESSION返回NFS4ERR_STALE_CLIENTID，需要重新分配clientid啃憎。
• 如果非SEQUENCE或者非SEQUENCE處理過的operation返回NFS4ERR_STALE_CLIENTID芝囤，需要重新分配clientid。

8.4.2.1 State Reclaim

在grace period中，每個client都去reclaim以前獲得的lock悯姊。這個期間羡藐，創(chuàng)建clientid和創(chuàng)建session是允許的，獲得lock操作全部駁回(NFS4ERR_GRACE)悯许，只有reclaim-type的操作允許仆嗦。

struct open_claim4 {
    open_claim_type4 claim;
    union {
        component4 file;
        open_delegation_type4 delegate_type;
        open_claim_delegate_cur4 delegate_cur_info;
        component4 file_delegate_prev;
        stateid4 oc_delegate_stateid;
    } open_claim4_u;
};

當創(chuàng)建clientdid并且創(chuàng)建Session后，發(fā)送reclaim-type lock請求岸晦。例如open操作的claim設置成CLAIM_PREVIOUS重新建立lock欧啤。當所有l(wèi)ock都恢復后睛藻，發(fā)送RECLAIM_COMPLETE操作启上。

8.4.3 Network Partitions and Recovery

如果Network Partitions時間超過lease時間。

8.5 Server Revocation of Locks

8.6 Short and Long Leases

8.7 Clocks, Propagation Delay, and Calculating Lease Expiration

9. File Locking and Share Reservations

為了支持Win32的share reservations,提供了原子操作OPEN和Create操作店印。以前OPEN由三個操作LOOKUP, CREATE, ACCESS完成冈在，NFS4.1由原子操作OPEN完成。

9.1 Opens and Byte-Range Locks

Read/Write擁有輕量級的lock語意按摘，Lock擁有重量級的lock語意包券。

9.1.1 State-Owner Definition

Open一個文件或對lock請求，由state-owner代表owner炫贤。

struct state_owner4 {
    clientid4 clientid;
    struct {
        u_int owner_len;
        char *owner_val; //可以由于thread ID溅固，process ID等值
    } owner;
};
typedef state_owner4 open_owner4;
typedef state_owner4 lock_owner4;

• 每個open和一個open-owner關聯(lián)
• 每個byte range lock和lock-owner/open-owner pair關聯(lián)。
• 每個Delegations和layouts兰珍，不和某個owner關聯(lián)侍郭，和clientid關聯(lián)。

9.1.2 Use of the Stateid and Locking

READ/WRITE/SETATTR都帶著stateid
READ/WRITE的stateid指定lock類型掠河，區(qū)分byte-range locks或是 share reservations亮元。如果都不是則是special stateid(zero as the value for "other" and "seqid")。如果share reservations或者byte-range locks有conflict則返回NFS4ERR_LOCKED唠摹。

9.4 Stateid Seqid Values and Byte-Range Locks

LOCK和LOCKU操作爆捞，stateid中的other不變，seqid自增勾拉。

9.7 Share Reservations

OPEN操作時候煮甥，指定是access類型:

• OPEN4_SHARE_ACCESS_READ
• OPEN4_SHARE_ACCESS_WRITE
• OPEN4_SHARE_ACCESS_BOTH
  同時指定deny類型:
• OPEN4_SHARE_DENY_NONE
• OPEN4_SHARE_DENY_READ
• OPEN4_SHARE_DENY_WRITE
• OPEN4_SHARE_DENY_BOTH

9.8 OPEN/CLOSE Operations

CLOSE操作釋放Share Reservations和range lock。

9.9 Open Upgrade and Downgrade

如果OPEN已經(jīng)有了open-owner藕赞，這時候再來一個OPEN,就是Open Upgrade苛秕。

10. Client-Side Caching

10.1 Performance Challenges for Client-Side Caching

以前在open的時候做cache validation，這個效率不高找默。原因是大部分文件都是不share的艇劫。

10.2 Delegation and Callbacks

Recallable delegation可以減少對server的請求。
Delegation是針對client，但不針對client某個具體進程或線程店煞。
delegation是從server=>client,為了保持backchannel暢通蟹演，需要不時發(fā)送僅帶一個operation的CB_COMPOUND，CB_SEQUENCE判斷backchannel暢通

10.2.1 Delegation Recovery

需要考慮:

• client restart
  當Client重啟后顷蟀，對于Share Reservations和range lock,Server立刻回收酒请。但對于delegation,需要等待client重連，這是因為可能有些數(shù)據(jù)沒有及時更新到Server鸣个。對于open delegation,OPEN的claim type設成CLAIM_DELEGATE_PREV or CLAIM_DELEG_PREV_FH
• server restart
• network partition (full or backchannel-only)

10.3 Data Caching

10.3.1 Data Caching and OPENs

• OPEN操作后有要驗證(revalidate)cache羞反。先獲取change屬性，比較是否變化囤萤。
  至少在open時候指定OPEN4_SHARE_DENY_WRITE或OPEN4_SHARE_DENY_BOTH時昼窗，revalidate cache。
  data和metadata更新導致change屬性更新涛舍。data更新會導致time_modify屬性更新澄惊。
• OPEN時候指定OPEN4_SHARE_ACCESS_WRITE，在CLOSE時候需要flush富雅。

10.3.2 Data Caching and File Locking

N/A

10.4 Open Delegation

N/A

10.5 Data Caching and Revocation

N/A

10.6 Attribute Caching

本節(jié)討論在不獲得delegation的情況下掸驱，對file attribute的緩存。
對attribute的修改不應緩存没佑，而應立刻向server發(fā)送修改請求毕贼。但對數(shù)據(jù)緩存強相關的attribute除外。例如修改文件蛤奢，使文件變長了鬼癣，文件大小的屬性可以不立即更新服務器。當緩存的數(shù)據(jù)更新到server的同時远剩，這個屬性也同時更新扣溺。
由于緩存，不同client端的attribute可能不一致瓜晤。文件系統(tǒng)也沒有提供一個接口可以原子的修改attribute锥余。 下面的規(guī)則應用于以前的NFS協(xié)議:

• 在本地緩存attribute有個上限時間，超過這個時間會重新從server端獲取痢掠。
• Client對文件/目錄的寫操作驱犹，緊跟著GETATTR操作獲取所修改的attribute
  Client獲取最新的change和time_access,將本地緩存change和獲取的change比較。如果相等說明attribte緩存還是有效(但time_access更新至剛才獲取的)足画，否則失效雄驹。

10.7 Data and Metadata Caching and Memory Mapped Files

如果有page fault就會去sever讀數(shù)據(jù)，并且讀取屬性(time_access, time_metadata, time_modify, change)

• 如果有個程序在server端淹辞，client端不可能通過比較change屬性來判讀數(shù)據(jù)是否失效(change屬性必須由client修改)医舆。client端可以總是詢問Server端，但這效率低，一般不用蔬将。
• client端從本地緩存獲取數(shù)據(jù)爷速，但time_access沒有得到更新。