RFC5661

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: 根据EXCHANGE_ID传进来的client_owner4进行confirm
  它们取代了NFS4的SETCLIENTID和SETCLIENTID_CONFIRM。

struct client_owner4 {
        verifier4       co_verifier;//client重启后会变化
        opaque          co_ownerid;//client重启后不会变化
};

2.5 Server Owners

类似Client Owners，但没有server id的概念。

struct server_owner4 {
    uint64_t       so_minor_id;
    opaque         so_major_id;
};

此信息是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相关联，并不和session关联。Session A用来获取delegation,而recall delegation可以发生在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联系。每个connection和1个或2个channel联系。这个个数是由CREATE_SESSION和BIND_CONN_TO_SESSION操作时确定的。connection和session的联系并不排他，即其他connection也可以和同一个Session联系。

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，关联到同一个session。如果两个连接的目标地址一样，就必须支持session trunking。
client ID trunking是将多个相同clint ID的session关联起来。如果两个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发送Write A到Server
2. 由于network partition，response没有返回
3. Client重新发送Write A到Server
4. Client的第二次的Write A得到response
5. Client发送Write B(这个操作和第一次的Write A会产生overlap)
   真正意义上的EOS是很难实现的，它需要永不重启，保存reply cache。

2.10.6.1 Slot Identifiers and Reply Cache

RPC的XID(transaction ID)不适合跟踪请求是否请求过。
NFSv4.1 reply cache使用slot id,取值范围是0~N,N的数值取决于CREATE_SESSION的ca_maxrequests返回值。也可以在后面的SEQUENCE和CB_SEQUENCE操作中调节。在同一个session中，可以ca_maxrequests个并发请求(决定着在这个Session并发的最大数量)，每个请求从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协议无关，而是作为应用程序的特殊需求。

8. State Management

Lock的引入，导致了nfs有状态，Sever端维护这个状态。用一个128bit的stateid描述 ，它可能代表一个open file, 一组range lock,a recallable delegation

8.1 Client and Session ID

在执行open, byte-range lock,delegation和过得layout之前, Client需要创建一个clientid和若干个sessionid。这个sessionid和clientid有所联系。sessionid作为client的一个 shorthand reference。对于一些lock来说，client还代表被称作owner的实体。对于其他lock来说(delegation,layout)，并没有这样的中间的实体对应。

8.2 Stateid Definition

当Server grant了某种lock,他就会返回一个stateid来表示这些lock。由不同open owner打开同一个文件，会对应同一个stateid。
给定stateid，Sever可以获得联系的的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:状态变化是自增，初始值为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看到的数据需要一致。

8.4.1 Client Failure and Recovery

Client的lease过期后，Sever释放相关的lock。
为了缩短client因restart导致的delay,lock操作和client_owner4中的verifier关联。对于EXCHANGE_ID操作， Sever返回clientid。Clientg确认clientid后，进一步建立Session。Client重启后，verifier会变。Server会比较这个verifier和lock关联的verifier，如果不一致说明client重启。

8.4.2 Server Failure and Recovery

Server在grace period恢复lock的状态。Client可以通过这些办法判断丢掉lock

• SEQUENCE和其他operation,返回NFS4ERR_BADSESSION,代表session被Destory,但clientid还有效。此时可以CREATE_SESSION重建Session。如果CREATE_SESSION返回NFS4ERR_STALE_CLIENTID，则表明clientid失效。
• SEQUENCE和其他operation,返回NFS4ERR_DEADSESSION，代表session已经不可用。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。这个期间，创建clientid和创建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;
};

当创建clientdid并且创建Session后，发送reclaim-type lock请求。例如open操作的claim设置成CLAIM_PREVIOUS重新建立lock。当所有lock都恢复后，发送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关联
• 每个byte range lock和lock-owner/open-owner pair关联。
• 每个Delegations和layouts，不和某个owner关联，和clientid关联。

9.1.2 Use of the Stateid and Locking

READ/WRITE/SETATTR都带着stateid
READ/WRITE的stateid指定lock类型，区分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已经有了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畅通，需要不时发送仅带一个operation的CB_COMPOUND，CB_SEQUENCE判断backchannel畅通

10.2.1 Delegation Recovery

需要考虑:

• client restart
  当Client重启后，对于Share Reservations和range lock,Server立刻回收。但对于delegation,需要等待client重连，这是因为可能有些数据没有及时更新到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

本节讨论在不获得delegation的情况下，对file attribute的缓存。
对attribute的修改不应缓存，而应立刻向server发送修改请求。但对数据缓存强相关的attribute除外。例如修改文件，使文件变长了，文件大小的属性可以不立即更新服务器。当缓存的数据更新到server的同时，这个属性也同时更新。
由于缓存，不同client端的attribute可能不一致。文件系统也没有提供一个接口可以原子的修改attribute。 下面的规则应用于以前的NFS协议:

• 在本地缓存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读数据，并且读取属性(time_access, time_metadata, time_modify, change)

• 如果有个程序在server端，client端不可能通过比较change属性来判读数据是否失效(change属性必须由client修改)。client端可以总是询问Server端，但这效率低，一般不用。
• client端从本地缓存获取数据，但time_access没有得到更新。