RFC5661

2019-03-04  本文已影响0人  帆子_8c3a

RFC文档

1. Introduction

1.6 General Definitions

1.8 Differences from NFSv4.0

2. Core Infrastructure

2.4 Client Identifiers and Client Owners

Clientid是64-bit ID,由server分配。Client和Sever重启，都会导致Clientid变化。一个Session对应一个clientid。
大部分操作必须在这两个操作之后：

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的问题

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，即下列的值有相同含义:

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，一定只运行一次。需要了解以下概念：

  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属性：

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

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。

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

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;

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类型:

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

需要考虑:

10.3 Data Caching

10.3.1 Data Caching and OPENs

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协议:

10.7 Data and Metadata Caching and Memory Mapped Files

如果有page fault就会去sever读数据，并且读取属性(time_access, time_metadata, time_modify, change)

上一篇 下一篇

猜你喜欢

热点阅读