ycnian

前面几篇文章基本介绍清楚了LAYOUTGET和GETDEVICEINFO两个请求，这是客户端发起I/O操作前的准备工作，这篇文章中我们就以读操作为例讲讲pNFS中的I/O操作。pNFS中的读操作和没有采用pNFS机制时的读操作基本流程是一致的，只是部分步骤有差别，这篇文章主要关注差别之处。static const struct nfs_pageio_ops filelayout_pg_read

这篇文章讲讲服务器端RPC报文的处理流程。服务器端RPC报文的处理函数是svc_process，这个函数位于net/sunrpc/svc.c中。这个函数需要一个svc_rqst结构的指针作为参数，svc_rqst是与RPC请求相关的一个数据结构，这里包含了接收到的RPC消息，RPC消息的解析结果也放在这个数据结构中，RPC消息的处理结果也放在这个消息中了。这个数据结构的定义在include/lin

NFSv2和NFSv3是无状态协议，服务器不需要记录客户端状态，只需要监听并响应客户端的请求就可以了。而NFSv4是一种有状态的协议，服务器需要记录客户端的状态，需要处理客户端的各种异常情况。NFSv4中，每个客户端用一个8字节的数字表示，这个数据称为clientid，服务器端可以保证任何两个客户端的clientid不相同。与clientid相关的两个请求是SETCLIENTID和SETCLIEN

NFS是一种跨操作系统的协议，Linux客户端可以挂载Windows服务器中的文件系统，Mic客户端也可以挂载Solaris服务器中的文件系统。Linux中，NFS客户端和NFS服务器端是分别开发的，客户端的程序位于fs/nfs/中，目前由NetApp的Trond Myklebust维护；服务器端的程序位于fs/nfsd中，由RedHat的J. Bruce Fields维护。前面几篇文章讲解了服务

NFS是Sun在上世纪80年代推出的一款网络文件系统，目前已经发展到了第四代。通过NFS文件系统，我们可以像访问本地文件一样访问其他主机上的文件。在客户端挂载NFS文件系统之前，服务器端需要进行一些设置。第一步操作就是指定导出的文件系统，这是在文件/etc/exports中配置的。导出文件系统时管理员可以设置一些参数，限制用户的访问权限。概括来说，管理员可以设置下列参数：1.rw an

1.网络拓扑结构        本次pNFS部署过程采用的是iSCSI+GFS+pNFS技术，其中pNFS选取的是file layout。系统由四台机器构成，拓扑结构如下图所示：192.168.6.145：这台机器作为iSCSI的Target端，对内核版本没有要求，只要能支持iSCSI就可以了。192.168.6.180：这台机器作为iSCSI的一个initia

1 file layout中的基本概念    pNFS支持三种LAYOUT，分别为：block layout、object layout、file layout。这篇文章中讲解file layout的设计理念，不涉及Linux中的代码。首先介绍几个概念，这些概念见RFC5661第13章。Unit: Unit是固定长度的数据块，因为pNFS中可以包含多个DS，客户端可以向多个DS发送数据

这篇文章中我们先说说deviceid。什么是deviceid呢？在使用pNFS的情况下，客户端执行I/O操作前需要先获取文件的layout。同时客户端需要获取DS的详细信息，比如DS的IP地址，否则客户端还是没办法发起I/O请求。deviceid就包含了DS的基本信息。客户端中deviceid用数据结构struct nfs4_deviceid表示：#define NFS4_DEVICEID

上一篇文章讲解了客户端deviceid相关的数据结构和操作函数，这篇文章中讲讲MDS中与deviceid相关的数据结构和操作。当MDS接收到GETDEVICEINFO请求后，会解析报文，解析出的数据存放在数据结构struct nfsd4_pnfs_getdevinfo中了，这个数据结构定义如下：struct nfsd4_pnfs_getdevinfo { struct nf

上篇文章讲到了MDS中LAYOUTGET的处理过程，当MDS处理完毕后就会将数据封装到应答消息中返回给客户端。这篇文章中我们讲讲客户端接收到应到报文后的处理。以前的文章讲到过客户端用struct pnfs_layout_segment表示一个layout，LAYOUTGET的作用就是获取文件的layout，因此当客户端接收到LAYOUTGET应答报文后会创建一个pnfs_layout_segmen

现在可以讲解LAYOUTGET请求了，首先我们需要回忆一下NFS文件系统中读数据的过程，看看LAYOUT请求是什么时候触发的。NFS文件系统中，每个缓存页关联了一个数据结构struct nfs_page。同时客户端还定义了一个数据结构struct nfs_pageio_descriptor，这个结构中包含了一个链表。当客户端向服务器请求数据时，会把缓存页挂载到这个数据结构的链表中，添加到这个链表中

这篇文章中讲解nfs4_pnfs_get_layout()的执行过程，有些复杂，首先讲讲layout在MDS中的保存方式。MDS中有两个数据结构跟layout相关，分别是struct nfs4_layout_state和struct nfs4_layout。struct nfs4_layout表示一个layout，这个数据结构定义如下：/* outstanding layout */st

前面一篇文章讲到了nfs4_pnfs_get_layout()最终调用struct pnfs_export_operations结构中的layout_get()创建一个新的layout，这篇文章中就详细讲讲file layout中layout的创建过程。file layout中的pnfs_export_operations定义如下：const struct pnfs_export_oper

上一篇文章中我们讲解了一个RPC请求的处理流程，其中涉及到了RPC请求报文中的认证信息。Linux支持多种认证方式，不同的认证方式中认证信息的内容是不同的，需要按照认证方式进行处理。这篇文件中我们以UNIX认证为例，详细讲解UNIX认证方式中认证信息的处理过程。        Linux中，每种认证方式用数据结构auth_ops表示，每种认证方式都需要实现这个数据结构中的函数。struct

上一篇文章讲解了函数nfs_readpages()的整体流程，这个函数的作用是向服务器发起READ请求，用请求到的数据更新缓存页中的内容。这个函数分为六个步骤：步骤1：获取用户信息。步骤2：检查FS-Cache缓存是否有效。步骤3：初始化一个nfs_pageio_descriptor结构。步骤4：将链表pages中的缓存页添加到文件缓存的radix树中，然后为每

SETCLIENTID请求中，服务器为客户端设置了clientid，但是客户端不能马上使用这个clientid，必须先向服务器发起SETCLIENTID_CONFIRM请求，确认接收到了clientid，然后才能使用。1.客户端代码SETCLIENTID_CONFIRM使用的数据结构struct nfs4_setclientid_res { u64

上篇文章中我们讲到了Linux中clientid的协商过程，这个过程是由函数nfs4_init_clientid()实现的。这个函数包含两个步骤：（1）发起SETCLIENTID请求，由函数nfs4_proc_setclientid()实现；（2）发起SETCLIENTID_CONFIRM请求，由函数nfs4_proc_setclientid_confirm()实现。这篇文章中我们详细详解SETC

这篇文章接着讲解nfs_readpages()的流程。上篇文章中，我们讲到了read_cache_pages()将缓存页添加到文件缓存的radix树中，为每个缓存页创建了一个nfs_page结构，然后将这些缓存页链接到nfs_pageio_descriptor结构中。nfs_pageio_descriptor中包含了多个缓存页以及向服务器请求数据的函数集合。接下来就是调用nfs_pageio_de

上一篇文章中我们讲解了NFS文件系统中读操作的主要流程。如果缓存页中的数据有效，直接将缓存页中的数据拷贝到用户态缓冲区中。如果缓存页中的数据无效，则需要调用nfs_readpages()更新缓存页中的数据。nfs_readpages()完整定义如下：// 这是NFS文件系统的readpages()函数// pages是一个缓存页链表，nr_pages是链表中缓存页的数量// 需要将链表中的

Linux应用程序通过read(2)读取文件中的数据，read(2)最终调用了文件系统的read函数。在NFS文件系统中，这个函数是do_sync_read()，这也是一个通用函数，调用了文件系统的aio_read()函数。NFS文件系统中的aio_read()是nfs_file_read()。ssize_tnfs_file_read(struct kiocb *iocb, const st

前面的文章中我们讲解了一个RPC请求的处理流程。一个RPC请求的基本处理过程包含三个步骤：(1)解析RPC报文头；(2)验证用户身份；(3)处理这个请求。前两个步骤我们已经讲过了，这篇文章详细讲讲第三个步骤的具体处理过程。为了简单起见，这里挑选了一个简单的请求REMOVE。一个NFS请求的处理过程分成三个步骤1.解码RPC请求报文净荷中的NFS数据。2.处理NFS请求。3.将处理结

由于多个客户端可以挂载同一个文件系统，如何在多个客户端之间保持数据一致性是个非常麻烦的问题，NFSv2和NFSv3没有规定具体的方法，一般的做法是客户端不定期检查文件是否发生了冲突，比如读操作中在发起READ请求前可能要发起GETATTR请求，判断本地缓存是否有效。在大规模系统中以及当客户端和服务器分布比较遥远时就会影响系统性能，因为GETATTR操作需要一定的执行时间。    NFSv4引入

接着前面的内容讲，这篇文章主要介绍了nfs_readpages()函数中的步骤4，步骤4中包含下面一条语句ret = read_cache_pages(mapping, pages, readpage_async_filler, &desc);read_cache_pages()是一个通用函数（不是NFS中的函数），这个函数定义在mm/readahead.c，这个函数的完整定义如下：

挂载NFS文件系统后，客户端就可以像访问本地文件一样访问服务器端的文件。NFS客户端根据RFC中的规定将用户操作封装到RPC请求报文中发送给服务器端，服务器端接收到RPC请求后进行处理，将处理结果封装到RPC应答报文中返还给客户端。这篇文章中我们讲讲客户端RPC请求报文的封装过程。LInux中RPC的代码位于net/sunrpc/中，客户端和服务器端的代码都在这个目录中。首先介绍几个数据结构，只说

上一篇文章中我们讲解了NFS中文件句柄的作用以及组装过程，文件句柄由函数fh_compose()组装，这个函数的声明如下：__be32 fh_compose(struct svc_fh *fhp, struct svc_export *exp, struct dentry *dentry, struct svc_fh *ref_fh)fhp是输出参数，生成的文件句柄就保存在这个变量中了

上一篇文章中我们以REMOVE请求为例讲解了NFS请求的处理过程，其中提到了文件句柄的概念，NFS需要根据文件句柄查找一个文件，这篇文章中我们就来聊聊文件句柄。在普通的文件系统中，我们用文件索引节点编号(ino)表示一个文件。ino就是一个数字，ino保存在磁盘中，整个文件系统中任何两个文件的ino都不相同，因此给定一个ino，我们就能找到对应的文件。当使用NFS文件系统时就出现问题了，我们无法通

服务器端开启NFS服务后，客户端就可以挂载了。客户端可以像操作本地文件系统一样操作NFS文件系统。客户端在挂载NFS文件系统时可以加一些选项，一般可以指定下列选项。1. soft and hard前面的文章中提到过，客户端和服务器通过RPC机制进行通信，客户端向服务器发送RPC请求，服务器解析RPC请求中的信息进行处理，然后向客户端发送应答消息。RPC请求具有一个超时时间，如果在这个时间内

上一篇文章中我们分析了layout在客户端的保存形式、相关的数据结构、客户端发起LAYOUTGET请求的时间点，这篇文章中我们详细分析一下LAYOUTGET请求的发起过程以及MDS端的处理过程。1.客户端处理程序首先看几个客户端的数据结构：struct nfs4_layoutget { // LAYOUTGET请求报文中的数据 struct nfs4

pNFS系统的部署过程见这篇文章：http://blog.csdn.net/ycnian/article/details/8523193。这篇文章中我们讲讲MDS的初始化过程，主要想讲讲向文件/proc/fs/nfsd/pnfs_dlm_device中写入数据后MDS做了哪些工作，以下面这条命令为例。[root@180 ~]# echo "sdb:192.168.6.180,192.168

1.CLOSE和OPEN_DOWNGRADE    客户端用户执行完读写操作之后就需要关闭文件了，一般情况下客户端用户调用close(2)关闭文件。NFS文件系统中有两个请求与关闭文件相关：CLOSE和OPEN_DOWNGRADE。CLOSE：这个请求的作用是释放OPEN请求中申请的stateid。客户端在OPEN操作中向服务器申请了stateid，stateid表示了客户端用户请求的

1.OPEN请求报文和应答报文中的数据        OPEN操作比较复杂，涉及到很多种特殊情况。按照RFC3530的规定，OPEN请求报文中需要包含下列数据：struct OPEN4args { seqid4 seqid; // 这是一个序号，保证请求能够序列化. uint32_t share_acce

NFSv4是一种有状态的协议，客户端需要记录用户操作的各种状态。当用户打开文件时客户端需要记住各个文件的状态。不考虑文件锁的情况下，跟文件状态相关的两个数据结构是nfs4_state_owner和nfs4_state。nfs4_state_owner表示客户端一个用户，包含了这个用户打开的所有文件，而nfs4_state表示用户打开的一个文件，这几个数据结构之间的关系如下图所示。

原文地址：http://www.redhat.com/magazine/008jun05/features/gfs_nfs/Red Hat® GFS vs. NFS: Improving performance and scalabilityby Matthew O'KeefeData sharing is a must in today's modern computin

pNFS是NFSv4.1最主要的特色，主要目的是为了解决系统吞吐量问题。随着网络和并行计算的迅猛发展，文件IO成为了限制系统整体性能的瓶颈。以前的版本中，所有的客户端与一个服务器连接，所有的请求都必须由这个服务器处理，这不适应并行计算的环境。Linux中pNFS正处于开发阶段，pNFS客户端程序已经合并到Linus Torvalds的主线库中，但是处于EXPERIMENTAL状态，pNFS服务器端

nfs4_state_owner代表了客户端的一个用户，包含了这个用户打开的所有文件的信息。每个文件用数据结构nfs4_state表示，每打开一个文件就向nfs4_state_owner中添加一个nfs4_state结构。因此，OPEN操作中首先要检查客户端是否为当前用户创建了nfs4_state_owner结构，如果没有就创建一个。这个流程是由函数nfs4_get_state_owner()实现

NFS是一种网络文件系统，从1985年推出至今，共发布了3个版本：NFSv2、NFSv3、NFSv4，NFSv4包含两个次版本NFSv4.0和NFSv4.1。经过20多年发展，NFS发生了非常大的变化，最大的变化就是推动者从Sun变成了NetApp，NFSv2和NFSv3基本上是Sun起草的，NetApp从NFSv4.0参与进来，并且主导了NFSv4.1标准的制定过程，而Sun已经被Oracle收

ACCESS是NFSv3中增加的一个请求，这个请求的作用是检查用户对文件的访问权限。由于服务器端可能对用户进行匿名映射，因此通常的uid/gid机制就不起作用了。NFSv2中客户端直接向服务器发起各种请求（如READ和WRITE）。如果用户没有相应的访问权限，则失败，客户端进行处理。NFSv3中客户端先通过ACCESS检查用户的访问权限，如果权限不满足就不发起后续请求了。如果权限满足，再发送后续请

1.nfs_writepages    nfs_file_write()是NFS系统中的写操作函数，这个函数将用户态缓冲区中的数据写入到内核态缓存页中。如果是同步写操作，则马上调用vfs_fsync()将缓存页中的数据刷新到服务器中。如果不是同步写操作，则客户端定期将缓存页中的数据刷新到服务器中。无论哪种情况，最终都需要调用address_space_operations结构中的writepa

1.nfs_file_writeNFS文件系统中write操作过程和read操作过程类似，区别在于read操作从服务器读取数据到客户端，write操作将数据从客户端写到服务器中。NFS文件系统中write操作的处理函数是nfs_file_write()。ssize_t nfs_file_write(struct kiocb *iocb, const struct iovec *iov,

NFS文件系统中WRITE操作比READ操作要复杂一些。READ操作中只需要将数据从服务器中读取到客户端的缓存页中就可以了，但是WRITE操作中客户端可能将数据写入到服务器的缓存页中，也可能写入到服务器的磁盘中。如果数据写入到服务器的缓存页中了，客户端还需要在适当的时候发起COMMIT请求将数据写入到服务器的磁盘中。1.WRITE请求的结构RFC1818规定了WRITE请求报文和应答报文的