我们现在测试使用的 Chelsio T4 及 T5 系列万兆以太网卡支持 iWARP RDMA 功能，查阅文档之后发现此系列的万兆网卡除了支持常用的基于 IP 协议的 iSCSI 以及 NFS-RDMA 之类的功能，Chelsio 还特别提供了基于 RDMA 的 Block 设备驱动（以下简称 RBD 驱动）。

RDMA 技术本身我就不做详细介绍了，Chelsio 提供的 RBD 驱动则支持通过 iWARP 网卡的 RDMA 连接在 Linux 系统中虚拟新的块设备，其架构如下图所示，可以看到也是 target - initiator 模式：

RDMA Block 设备驱动架构

基于 iWARP 的 RBD 对比 iSCSI 等技术可以显著提高性能及降低延迟，虽然 RBD 驱动目前仍然处于测试阶段，只支持 Linux 系统，而且也存在一些限制：

• 最大 RBD I/O 大小为 128 KB；
• Outstanding I/O 最大为 256；
• 目前物理和逻辑扇区都固定为 4 KB。

但看起来并不妨碍我们拿来做一些简单的测试的。

测试环境

• Chelsio T420-CR 双口 10Gbps 万兆网卡；
• 万兆网卡都使用 PCI-E 2.0 x 8 插槽；
• 服务器和客户端均采用 Linux 64 位 3.18 版本 kernel；
• 万兆网卡及 RDMA Block 设备驱动使用 ChelsioUwire-2.11.1.0 版本；
• 服务器和客户端使用直连方式连接。

测试步骤

配置万兆网卡

首先分别在服务器和客户端安装 ChelsioUwire 驱动，如果一切正常的话系统应该能自动加载 cxgb4 万兆网卡驱动及对应的 iWARP 驱动：

~ # lsmod | grep iw
iw_cxgb4 145655 0
iw_cm 21013 1 rdma_cm
ib_core 53913 13 xprtrdma,svcrdma,ib_ipoib,rdma_ucm,ib_ucm,ib_uverbs,ib_umad,rdma_cm,ib_cm,ib_sa,ib_mad,iw_cxgb4,iw_cm
cxgb4 300161 1 iw_cxgb4

提示

为了让需要支持 RDMA 的应用程序也能正常使用 InfiniBand Verbs API 功能，建议同时安装 Chelsio 万兆网卡的 cxgb4 驱动对应的 RDMA 用户模式驱动程序 libcxgb4（libcxgb4-rdmav2.so）。

如果没有正确加载 iWARP 驱动那也可以尝试手工加载 RDMA 相关驱动：

~ # modprobe iw_cxgb4
~ # modprobe rdma_ucm

接下来为万兆网卡配置 IP 地址，为了测试性能考虑可以将两端的万兆网卡 MTU 值修都改为 9000，假设服务器和客户端的 IP 地址分别为：

• 10.10.1.1
• 10.10.1.2

测试 RDMA 连接

这里我使用 rping 工具测试 RDMA 连接，rping 工具可以兼容所有支持 RDMA 功能的协议，例如：InfiniBand、RoCE、iWARP 等。CentOS 等系统中可以安装 librdmacm 软件包支持 rping 工具，对应的 Ubuntu 等系统中也可以使用 rdmacm-utils 软件包。

rping 命令的 -a 参数指定要监听（服务器端）或者连接（客户端）的地址，对于 Infiniband 需要启用并配置 IPoIB 网卡并使用 IPoIB 接口设备的 IP 地址，而对于 RoCE 和 iWARP 则可以直接使用网卡接口设备的 IP 地址。

我测试的 Chelsio 万兆网卡就是支持 iWARP 的，因此可以直接使用上面列出的网卡 IP 地址进行测试，分别看看服务端和客户端的使用方式和测试结果，rping 命令的 -s 参数指定当前主机做服务端：

~ # rping -s -a 10.10.1.1 -v
server ping data: rdma-ping-0: ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
server ping data: rdma-ping-1: BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
server ping data: rdma-ping-2: CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst
server ping data: rdma-ping-3: DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu
server DISCONNECT EVENT...
wait for RDMA_READ_ADV state 9

rping 命令的 -c 参数指定客户端，-a 参数指定服务器端地址，-C 参数和普通的 ping 命令类似：

~ # rping -c -a 10.10.1.1 -v -C 4
ping data: rdma-ping-0: ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
ping data: rdma-ping-1: BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
ping data: rdma-ping-2: CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst
ping data: rdma-ping-3: DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu
client DISCONNECT EVENT...

看起来 RDMA 连接是正常的，下面就可以编译 RDMA Block 设备驱动测试了。

测试 RBD 驱动

Chelsio RBD 驱动也在 ChelsioUwire 软件包中，假设一切安装正常，首先我们可以在服务器端建立卷设备，然后加载 RBD target 模式驱动：

~ # modprobe rbdt

至于 initiator 客户端则加载对应 RBD 驱动，并使用 rbdctl 命令添加 RDMA Block target：

~ # modprobe rbdi
~ # rbdctl -n -a 10.10.1.1 -d /dev/lv/rdmat -p 65000

上面 rbdctl 的 -a 参数指定 RBD 服务器端 iWARP 网卡 IP 地址，-d 参数指定需要访问的卷设备，-p 参数指定端口。

添加完成之后可以分别确认 target 和 initiator 端是否正常，先看看 target 端是否有正常的连接日志：

~ # tail /var/log/messages
Apr 20 17:06:42 node1 kernel: [17765.479389] rbdt: setting up rdma target on 0.0.0.0:65000
Apr 20 17:16:24 node1 kernel: [18348.143852] rbdt: connected 10.10.1.1:65000<->10.10.1.2:35010!

initiator 端应该能正确看到新的 RBD 设备了：

~ # tail /var/log/messages
Jan 20 17:13:07 node2 kernel: [ 2741.710561] rbdi: connected 10.10.1.2:35010<->10.10.1.1:65000!
Jan 20 17:13:07 node2 kernel: [ 2741.710658] rbdi: initialized /dev/rbdi0 (51201024 sectors; 209719394304 bytes)

这样就可以使用 /dev/rbdi0 设备进行各种读写性能相关测试了，根据 Chelsio 官方的测试数据，RBD 驱动的性能要比 Network Block Device（NBD 设备）好不少，已经比较接近 target 端本地读写的性能，而且延迟也控制的很好，我就不贴出详细数据咯。

另外运行过程中也可以查看 RBD 驱动的实时运行状态，下面是我在 RBD target 端看到的统计结果（kernel 需要开启 debugfs 支持）：

~ # cat /sys/kernel/debug/rbdt/rdmat/stats
reqs_started 656320
reqs_completed 656320
immd_writes 0
immd_reads 0
stall_sq_full 0
stall_ordq_full 0
max_outstanding_reqs 256
cq_waits 221261
max_rcq_polled 160
max_scq_polled 246

最近在 XFS 文件系统上使用 NFS 时发现一些比较老的 Linux 客户端在挂载时会提示 stale file handle 错误，这似乎是服务器端的 NFS 共享文件夹信息不正确了，比较奇怪为什么新的 Linux 系统又是可以挂载使用的，准备一探究竟。

首先登录到服务器端（也是 Linux 系统，RHEL6 x86_64 服务器），查看 NFS 共享文件夹的状态（NFS 共享路径为 /nfs/share2）：

/nfs # ls -dil *
    259 drwxrwxrwx    2 root     root             6 Jul 15 15:31 share1
4294967616 drwxrwxrwx    3 root     root            24 Jul 15 16:09 share2
/nfs # ls -dil share2/*
8589934912 drwxrwxrwx    2 root     root            24 Jul 15 16:09 share2/ppp
/nfs # ls -dil share2/ppp/*
8589934913 -rwxrwxrwx    1 root     root            15 Jul 15 16:15 share2/ppp/ooo

上面的 ls 命令特别增加了 -i 参数用于显示文件的 inode 值，这时就发现 /nfs/share2、/nfs/share2/ppp 这两个文件夹和 /nfs/share2/ppp/ooo 文件的 inode 值非常大，已经超过了一般的 32 位 inode 值限制，分别为：4294967616、8589934912、8589934913，而 /nfs/share1 文件夹的 inode 值则是 259。

查看运行 mount 命令发现 XFS 文件系统在挂载时使用了 inode64 参数指定使用 64 位的 inode 值来存储文件，使用 64 位 inode 主要用于解决容量非常大的文件系统在有可用空间但在使用 32 位 inode 值时可能还是无法再写入文件的问题的。然后就在之前不能挂载的 Linux 客户端上重新挂载 /nfs/share1 这个文件夹，结果却可以挂载了，看来很有可能就是 64 位 inode 造成不能挂载 /nfs/share2 共享文件夹的问题。

后来经过查找 kernel 中 NFS 文件系统的说明，Linux kernel 在 2.6.23 版本中可以直接支持 64 位的 NFS 文件 inode 值了，而且是通过给 nfs 这个内核模块增加 enable_ino64 参数来设置的，这个参数还是运行时可写的，一般新的发行版中如果 kernel 版本高于 2.6.23 都会支持的。另外有些发行厂商例如 RedHat 会在更新中提供支持，例如 RHEL 4 Update 7 这个比较老的系统中也支持 NFS 64 位 inode 值了。

下面在几个常见的 Linux 客户端系统中测试对 NFS 64 位 inode 的支持情况了：

1、Fedora Core 5 32位系统（内核版本：2.6.22）：

32 位的 Fedora Core 5 系统内核版本 2.6.22，虽然不支持 NFS 64 位 inode（也不支持 enable_ino64 参数），但还是能挂载的，而且使用时全部显示为 32 位 inode 值，看看效果：

[root@zzmlinux root]# mount -t nfs 192.168.1.145:/nfs/share2 /mnt
[root@zzmlinux root]# cd /mnt/
[root@zzmlinux mnt]# ls -dil
321 drwxrwxrwx  3 root root 24 Jul 15  2014 .
[root@zzmlinux mnt]# ls -dil *
322 drwxrwxrwx  2 root root 24 Jul 15  2014 ppp
[root@zzmlinux mnt]# cd ppp/
[root@zzmlinux ppp]# ls -dil *
323 -rwxrwxrwx  1 root root 5 Jul 15  2014 ooo
[root@zzmlinux ppp]# echo "test something" > ooo
[root@zzmlinux ppp]# cat ooo
test something

从上面的命令输出结果可以看出：

/nfs/share2 文件夹本身在服务器端的 inode 值原本为 64 位的 4294967616，但在 32 位的 NFS 客户端这被转换成了 321（其实：4294967616 = 0xFFFFFFFF + 321）。相应的 /nfs/share2/ppp 文件夹的 inode 值由 8589934912 转换为 322 了（8589934912 = 2 * 0xFFFFFFFF + 322），/nfs/share2/ppp/ooo 文件的 inode 值由 8589934913 转换为 323 了（8589934913 = 2 * 0xFFFFFFFF + 323）。

这样 NFS 客户端算是也能正常使用了，但不能保证文件数量太多时不会出现问题的。

2、RHEL 6 64位系统（内核版本：2.6.32）：

[root@localhost work]# mount -t nfs 192.168.1.145:/nfs/share2 /mnt/nfs
[root@localhost work]# ls -dil /mnt/nfs
4294967616 drwxrwxrwx 3 root root 24  7月 15 2014 /mnt/nfs
[root@localhost work]# ls -dil /mnt/nfs/ppp
8589934912 drwxrwxrwx 2 root root 24  7月 15 2014 /mnt/nfs/ppp
[root@localhost work]# ls -dil /mnt/nfs/ppp/ooo
8589934913 -rwxrwxrwx 1 root root 15  7月 15 2014 /mnt/nfs/ppp/ooo
[root@localhost work]# cat /mnt/nfs/ppp/ooo
test something

RHEL6 64 位系统上的效果就比较明显了，所有文件显示的 inode 值与服务器端的完全一致，这样使用起来就完全没有问题了。

3、Fedora 14 32位系统（内核版本：2.6.35）：

[root@fedora14 ~]# cat /sys/module/nfs/parameters/enable_ino64
Y
[root@fedora14 ~]# mount -t nfs 192.168.1.145:/nfs/share2 /mnt
[root@fedora14 ~]# ls -dil /mnt
4294967616 drwxrwxrwx 3 root root 24 Jul 15 16:09 /mnt
[root@fedora14 ~]# ls -dil /mnt/ppp
8589934912 drwxrwxrwx 2 root root 24 Jul 15 16:09 /mnt/ppp
[root@fedora14 ~]# ls -dil /mnt/ppp/ooo
8589934913 -rwxrwxrwx 1 root root 15 Jul 15 16:15 /mnt/ppp/ooo

这里由于 Fedora 14 是 32 位系统，我们在挂载 NFS 之前特地查看了 enable_ino64 参数，发现默认已启用的。这样在挂载之后查看到的文件的 inode 值也是和服务器一样为 64 位的了。如果有兴趣将 enable_ino64 参数改为 N 的话，你会发现这些 inode 也被转换为 32 位的了。

其实我碰到的主要就是 Linux 下老的程序和新的 64 位 inode 的兼容问题，SGI 推荐用户使用 64 位的 inode，btrfs 和 ext4 现在也开始准备改为 64 位 inode 了，当然不免还有一些老的程序存在兼容性问题，这里有 SGI 的研发人员实际测试 64 位 inode 的兼容结果：

http://blog.fmeh.org/2013/05/11/does-the-world-need-32-bit-inodes/

上面看到的只使用 32 位 inode 的程序占比结果 10% 还是比较令人满意的，只支持 32 位 inode 的程序现在越来越少了。

本文为个人测试及分析结果，如其中存在错误还请提出指正哦，玩的开心~~~ ^_^

Linux NFS 客户端在挂载服务器的 NFS 共享时可以使用 rsize 和 wsize 参数指定 NFS 读写的块大小，但实际使用时发现并不完全凑效，下面简单分析一下。

我先在一台 RHEL6 客户端上挂载另一台 RHEL6 服务器上的 NFS 共享：

[root@localhost ~]# mount -t nfs 192.168.1.122:/nfs/share /mnt/nfs
[root@localhost ~]# grep /mnt/nfs /proc/mounts
192.168.1.122:/nfs/share /mnt/nfs nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.122,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.122 0 0

从上面可以看到不指定 rsize 和 wsize 参数时，默认的读写块大小都是 256KB（rsize=262144），而且使用的是 TCP 协议（proto=tcp）。

下面使用 UDP 协议挂载 NFS 共享：

[root@localhost ~]# mount -t nfs -o udp 192.168.1.122:/nfs/share /mnt/nfs
[root@localhost ~]# grep /mnt/nfs /proc/mounts
192.168.1.122:/nfs/share /mnt/nfs nfs rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.122,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.122 0 0

从结果可以看出，使用 UDP 协议时块大小就只有 32KB 了。

准备在客户端这边修改 mount 参数将 NFS TCP 方式的读写块大小增加到 1MB：

[root@localhost ~]# mount -t nfs -o rsize=1048576,wsize=1048576 192.168.1.122:/nfs/share /mnt/nfs
[root@localhost ~]# grep /mnt/nfs /proc/mounts
192.168.1.122:/nfs/share /mnt/nfs nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.122,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.122 0 0

但从上面的结果来看，实际使用的块大小还是 256KB。

在客户端这边修改 mount 参数将 NFS UDP 方式的读写块大小增加到 256KB：

[root@localhost ~]# mount -t nfs -o udp,rsize=262144,wsize=262144 192.168.1.122:/nfs/share /mnt/nfs
[root@localhost ~]# grep /mnt/nfs /proc/mounts
192.168.1.122:/nfs/share /mnt/nfs nfs rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.122,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.122 0 0

UDP 模式下读写的块大小也无法修改，客户端似乎已经使用了最大的读写块大小。

没办法，下面来看看 Linux kernel 源代码，找出真正的原因，先在 include/linux/nfs_xdr.h 文件中找到了 NFS I/O 块大小的定义：

/*
 * To change the maximum rsize and wsize supported by the NFS client, adjust
 * NFS_MAX_FILE_IO_SIZE.  64KB is a typical maximum, but some servers can
 * support a megabyte or more.  The default is left at 4096 bytes, which is
 * reasonable for NFS over UDP.
 */
#define NFS_MAX_FILE_IO_SIZE    (1048576U)
#define NFS_DEF_FILE_IO_SIZE    (4096U)
#define NFS_MIN_FILE_IO_SIZE    (1024U)

这里可以看到 NFS 默认使用 4KB 块大小，客户端实际挂载时会做调整，最小 1KB，最大 1MB。

NFS 客户端在挂载时会与 NFS 服务器协商适合的读写块大小值，我们来看看 fs/nfs/client.c 文件中协商设置 NFS 文件系统信息的代码：

static void nfs_server_set_fsinfo(struct nfs_server *server, struct nfs_fsinfo *fsinfo)
{
	unsigned long max_rpc_payload;

	/* Work out a lot of parameters */
	if (server->rsize == 0)
		server->rsize = nfs_block_size(fsinfo->rtpref, NULL);
	if (server->wsize == 0)
		server->wsize = nfs_block_size(fsinfo->wtpref, NULL);

	if (fsinfo->rtmax >= 512 && server->rsize > fsinfo->rtmax)
		server->rsize = nfs_block_size(fsinfo->rtmax, NULL);
	if (fsinfo->wtmax >= 512 && server->wsize > fsinfo->wtmax)
		server->wsize = nfs_block_size(fsinfo->wtmax, NULL);

	max_rpc_payload = nfs_block_size(rpc_max_payload(server->client), NULL);
	if (server->rsize > max_rpc_payload)
		server->rsize = max_rpc_payload;
	if (server->rsize > NFS_MAX_FILE_IO_SIZE)
		server->rsize = NFS_MAX_FILE_IO_SIZE;
	server->rpages = (server->rsize + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;

	server->backing_dev_info.name = "nfs";
	server->backing_dev_info.ra_pages = server->rpages * NFS_MAX_READAHEAD;

	if (server->wsize > max_rpc_payload)
		server->wsize = max_rpc_payload;
	if (server->wsize > NFS_MAX_FILE_IO_SIZE)
		server->wsize = NFS_MAX_FILE_IO_SIZE;
	/*......*/
}

从上面 nfs_server_set_fsinfo 函数的代码可以看到 NFS 客户端实际参考了服务器返回的 rtmax 和 wtmax 值，而这个值可以在挂载 NFS 文件系统时用抓包工具看到（NFS 使用的 RPC 协议）。

下面的图片中显示的就是 NFS 客户端中指定 rsize 和 wsize 参数为 1MB 时 Wireshark 上抓到的 NFS FSINFO 请求的实际数据；

挂载NFS的网络抓包

上面图片里小椭圆圈表示的是 NFS FSINFO 请求，大椭圆圈里就是服务器传过来的 rtmax 和 wtmax 值了，我们可以看到值就是 256KB。这样也就能解释了为什么客户端增大 NFS 读写块大小也不起作用了。

我们后台登陆到 NFS 服务器上，可以从 /proc/fs/nfsd/max_block_size 文件中看到当前 NFS 服务器的最大块大小，然后尝试修改它：

~ # cat /proc/fs/nfsd/max_block_size
262144
~ # echo 524288 > /proc/fs/nfsd/max_block_size
~ # cat /proc/fs/nfsd/max_block_size
262144

可以看到当前 NFS 服务器的最大读写块大小确实是 256KB，但是我们想修改它的值的时候，却似乎又修改不了。这样只能再看看修改 max_block_size 的 kernel 源代码了，对应的代码在 nfsd/nfsctl.c 文件中：

static ssize_t write_maxblksize(struct file *file, char *buf, size_t size)
{
	char *mesg = buf;
	if (size > 0) {
		int bsize;
		int rv = get_int(&mesg, &bsize);
		if (rv)
			return rv;
		/* force bsize into allowed range and
		 * required alignment.
		 */
		if (bsize < 1024)
			bsize = 1024;
		if (bsize > NFSSVC_MAXBLKSIZE)
			bsize = NFSSVC_MAXBLKSIZE;
		bsize &= ~(1024-1);
		mutex_lock(&nfsd_mutex);
		if (nfsd_serv && nfsd_serv->sv_nrthreads) {
			mutex_unlock(&nfsd_mutex);
			return -EBUSY;
		}
		nfsd_max_blksize = bsize;
		mutex_unlock(&nfsd_mutex);
	}

	return scnprintf(buf, SIMPLE_TRANSACTION_LIMIT, "%d\n",
							nfsd_max_blksize);
}

write_maxblksize 函数中判断了传入的参数，如果写入的值超过 NFSSVC_MAXBLKSIZE 值则固定为 NFSSVC_MAXBLKSIZE 值，那我们来看看 NFSSVC_MAXBLKSIZE 的定义：

/*
 * Maximum blocksizes supported by daemon under various circumstances.
 */
#define NFSSVC_MAXBLKSIZE   RPCSVC_MAXPAYLOAD
/* NFSv2 is limited by the protocol specification, see RFC 1094 */
#define NFSSVC_MAXBLKSIZE_V2    (8*1024)

linux/nfsd/const.h 中 NFSSVC_MAXBLKSIZE 定义为了 RPCSVC_MAXPAYLOAD 的值，那看看 linux/sunrpc/svc.h 中 RPCSVC_MAXPAYLOAD 的实际值：

/*
 * Maximum payload size supported by a kernel RPC server.
 * This is use to determine the max number of pages nfsd is
 * willing to return in a single READ operation.
 *
 * These happen to all be powers of 2, which is not strictly
 * necessary but helps enforce the real limitation, which is
 * that they should be multiples of PAGE_CACHE_SIZE.
 *
 * For UDP transports, a block plus NFS,RPC, and UDP headers
 * has to fit into the IP datagram limit of 64K.  The largest
 * feasible number for all known page sizes is probably 48K,
 * but we choose 32K here.  This is the same as the historical
 * Linux limit; someone who cares more about NFS/UDP performance
 * can test a larger number.
 *
 * For TCP transports we have more freedom.  A size of 1MB is
 * chosen to match the client limit.  Other OSes are known to
 * have larger limits, but those numbers are probably beyond
 * the point of diminishing returns.
 */
#define RPCSVC_MAXPAYLOAD   (1*1024*1024u)
#define RPCSVC_MAXPAYLOAD_TCP   RPCSVC_MAXPAYLOAD
#define RPCSVC_MAXPAYLOAD_UDP   (32*1024u)

从 linux/sunrpc/svc.h 中可以看到 NFS 读写块大小必须为 2 的幂，这样也大概知道读写块大小限制的原因了：

对于 UDP 来说，由于一个 UDP 包最大才 64KB，因此使用 UDP 协议的 NFS 读写块大小最大不超过 48KB，而 kernel 中则直接限制为 32KB 了；而使用 TCP 协议的 NFS 由于没有这个限制允许更大的读写块大小，但 Linux kernel 还是将其限制为 1MB 了。

至于 max_block_size 值不能直接修改的现象也找到原因了，在 nfsd/nfsctl.c 文件中高亮显示的第 18 行代码里判断了 NFS 服务器是否在启动运行，如果在运行则不允许修改。

下面就好办了，先卸载 NFS 共享的挂载，停止服务器的 NFS 服务，修改 max_block_size 值，然后重新启动 NFS 服务，

~ # service nfs stop
Shutting down NFS mountd:                                  [  OK  ]
Shutting down NFS daemon:                                  [  OK  ]
Shutting down NFS services:                                [  OK  ]
~ # echo 1048576 > /proc/fs/nfsd/max_block_size
~ # cat /proc/fs/nfsd/max_block_size
1048576
~ # service nfs start

可以看到现在 NFS 的最大块大小可以修改了，接着在客户端中指定读写块大小并重新挂载 NFS 共享，这个时候客户端也能正确使用更大的块大小了：

[root@localhost fs]# mount -t nfs -o rsize=1048576,wsize=1048576 192.168.1.122:/nfs/share /mnt/nfs
[root@localhost fs]# grep /mnt/nfs /proc/mounts
192.168.1.122:/nfs/share /mnt/nfs nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.122,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.122 0 0

如果要深究一下 NFS 服务器初始的最大块大小只有 256KB 的原因，可以看看 kernel 中 nfsd/nfssvc.c 文件中的代码：

int nfsd_create_serv(void)
{
	int err = 0;

	WARN_ON(!mutex_is_locked(&nfsd_mutex));
	if (nfsd_serv) {
		svc_get(nfsd_serv);
		return 0;
	}
	if (nfsd_max_blksize == 0) {
		/* choose a suitable default */
		struct sysinfo i;
		si_meminfo(&i);
		/* Aim for 1/4096 of memory per thread
		 * This gives 1MB on 4Gig machines
		 * But only uses 32K on 128M machines.
		 * Bottom out at 8K on 32M and smaller.
		 * Of course, this is only a default.
		 */
		nfsd_max_blksize = NFSSVC_MAXBLKSIZE;
		i.totalram <<= PAGE_SHIFT - 12;
		while (nfsd_max_blksize > i.totalram &&
		       nfsd_max_blksize >= 8*1024*2)
			nfsd_max_blksize /= 2;
	}

	nfsd_serv = svc_create_pooled(&nfsd_program, nfsd_max_blksize,
				      nfsd_last_thread, nfsd, THIS_MODULE);
	if (nfsd_serv == NULL)
		err = -ENOMEM;
	else
		set_max_drc();

	do_gettimeofday(&nfssvc_boot);		/* record boot time */
	return err;
}

从上面的可以看到，NFS 服务器在决定默认的最大读写块大小时考虑到内存占用情况，每个 NFS 内核线程最多只使用 1/4096 的物理内存大小，对于物理内存超过 4GB 的机器才使用最大的 1MB 读写块大小。

来看看我们使用的 NFS 服务器的内存情况，可以看到服务器只使用了 2GB 的内存：

~ # free
             total       used       free     shared    buffers     cached
Mem:       2040272     335476    1704796          0       2360      70076
-/+ buffers/cache:     263040    1777232
Swap:            0          0          0

按照 nfsd/nfssvc.c 文件中的代码，i.totalram 实际值为所有可用的物理内存的页数量，我们这里就是 2040272 / 4KB（默认的 PAGE_SIZE 页大小），按照高亮的第 22 - 24 行代码计算出来的默认最大块大小值就是 262144 了。

本文为个人经过测试及分析 Linux kernel 源代码得出的分析结果，如果其中存在错误还请提出指正哦~~~ ^_^

在使用 CRM/Pacemaker 双机的时候，有时需要用到 Fencing/STONITH 技术来保证 I/O 数据的安全性。Fencing 分为资源级别和节点级别两种，资源级别的 Fencing 用于组织某个节点访问具体的资源，节点级别的 Fencing 用于确保某个节点不运行任何资源。关于 Fencing/STONITH 的详细介绍请参考 [这里]。

在实际使用 Pacemaker 的 Fencing 支持时会碰到两种常用的 fencing agent：LHA 类型和 RHCS 类型。Pacermaker 程序同时两种 fencing API：从 Heartbeat 继承而来的 fencing API（即 LHA 类型）和 Red Hat 自己实现的 cluster fencing API（即 Red Hat Cluster Suite 类型）。

RHCS fencing agent 就是 RHCS 集群套件中的一部分，如果需要使用 RHCS fencing agent 就同时需要使用 RHCS 中的其它组件。

RHCS 集群套件中包括：CMAN 仲裁组件支持、DLM 组件提供分布式锁支持、GFS 提供分布式文件系统支持、CLVM 支持、Red Hat Fencing 框架、Rgmanager 集群资源管理、pcs 集群管理工具（新版本中 DLM 和 GFS 已经是单独的软件包了）。DLM、GFS、CLVM、Red Hat Fencing 都依赖底层的 CMAN 组件。顺便说一句，如果双机的节点未启用 fencing 支持，是不允许加入 GFS 的。

Heartbeat STONITH 的介绍请参考这里：
http://www.linux-ha.org/wiki/STONITH
Redhat Fencing API 的介绍请参考这里：
https://fedorahosted.org/cluster/wiki/FenceAgentAPI

在不同的 Linux 系统平台上，pacemaker 软件包会根据应用场合提供不同类型的 fencing agent。

SUSE 系统上使用的是 LHA 类型 fencing agent，由 cluster-glue 软件包直接提供（cluster-glue 中包含其它基础双机支持），fencing agent 的程序或脚本通常位于 /usr/lib64/stonith/plugin 下的 external 等目录中，并由 stonithd 守护程序提供 STONITH 支持。

Fedora 和 RHEL 系统则使用 RHCS 类型 fencing agent，由单独的 fence-agents 软件包提供支持，安装之后的 fencing agent 的程序或脚本通常是 fence_xxxx 这种形式。Red Hat 将不同类型的 fencing agent 还打包成独立的包，因此有时候就需要安装类似这样的 fencing agent 支持：

fence-agents-ipmilan-4.0.0-5.el7.x86_64
fence-agents-drac5-4.0.0-5.el7.x86_64
fence-agents-wti-4.0.0-5.el7.x86_64
fence-agents-ifmib-4.0.0-5.el7.x86_64
fence-agents-eaton-snmp-4.0.0-5.el7.x86_64
fence-agents-eps-4.0.0-5.el7.x86_64
fence-agents-apc-4.0.0-5.el7.x86_64
...

最新的 Debian 和 Ubuntu 系统则做的更加彻底了，同时提供 LHA 和 RHCS 类型的 fencing agent 支持，并分别放在 cluster-glue 基础软件包和 fence-agents 软件包中。

从上面的说明来看，LHA 类型的 fencing agent 相对于 RHCS 来说确实是简单一些，不需要额外的 RHCS 组件就可以使用，也不需要安装额外的软件包，一般使用起来还是比较方便的。当然如果需要使用 RHCS 来实现 GFS 之类的功能，或者你是 Red Hat 的忠实拥趸的话，那使用 RHCS 来做 STONITH 也是没有问题的。

Windows Server 2012 系统中更新支持的 SMB 3.0 网络共享协议相对于原来的 SMB 1.0 有诸多改进，例如：RDMA 支持、Multichannel 多通道支持等等，详情请参考我之前写过的文章介绍如何在 Windows Server 2012 中使用 SMB 3.0 over RDMA：

https://zohead.com/archives/smb3-over-rdma-performance/

这里我主要关注 SMB 3.0 Multichannel 的实际效果，Multichannel 可以实现 SMB 客户端和服务器之间同时发起多个 SMB 连接（对于 SMB 1.0 和 2.0 是很大进步之一），通过在多网卡环境下使用 SMB 3.0 Multichannel 可以达到提高系统吞吐量、支持错误容忍、多通道自动配置等效果，从上面的文章中再来回顾下 SMB 3.0 的 Multichannel（多通道）需要的条件：

• SMB 服务器和客户端计算机必须都为 Windows Server 8 或者 2012；
• 必须都有多个网卡，网卡类型和速度需要一致，或者其中一个或多个网卡支持 RSS 或者 NIC Teaming（网卡绑定）或者 RDMA。

有一点需要说明的是 samba 新推出的 4.0 正式版本虽然提供了 SMB 3.0 协议的支持，但并不支持 Multichannel 多通道、RDMA 这些高级功能的，因此此测试暂时还只能在 Windows Server 2012 系统中做了。

测试环境

服务器：

Intel S5500BC 服务器主板；

Intel Xeon E5506 CPU * 1；

Kingston DDR3 1066 4G 服务器内存 * 1；

Intel EXPI9402PTBLK 双千兆网卡（PCI-E x 8 插槽）；

LSI MegaRAID 84016E RAID卡（PCI-E x 8 插槽）；

WD WD10EVDS 1TB SATA 监控硬盘 * 16；

Windows Server 8 Beta Datacenter Build 8250 64位中文版；

客户端：

TYAN S7002 服务器主板；

Intel Xeon E5506 CPU * 1；

Kingston DDR3 1066 2G 服务器内存 * 1；

主板内置双千兆网卡；

Windows Server 8 Beta Datacenter Build 8250 64位中文版；

其它环境：

TP-LINK 24 口千兆交换机；

测试软件：

IBM Tivoli SANergy（测试大块文件连续读写）；

测试步骤及结果

SMB Multichannel 在 Windows Server 2012 系统中默认就是启用的，你可以分别在服务器和客户端中的 PowerShell 中运行 Get-SmbServerConfiguration 和 Get-SmbClientConfiguration 命令查看 Multichannel 是否已经启用。

然后可以在 PowerShell 中分别运行 Get-SmbServerNetworkInterface 和 Get-SmbClientNetworkInterface 命令查看是否满足多通道的条件。以我的实际测试环境为例，先看看服务器上的配置：

从图中可以看到服务器中是两个千兆网卡，两个网卡的 IP 地址在同一网段，Interface Index 为网卡的序号（后面会用到），另外会显示 RSS 和 RDMA 都是不支持的，此时表示可以使用多通道。需要说明的是如果两个网卡都是千兆的，但是一个支持 RSS，另一个不支持 RSS，SMB 3.0 Multichannel 在类似这种情况下也是不能使用的。

再来看看客户端上的网卡情况：

客户端的网卡多一些，但我们只需看网络通了的网卡（Interface 12 和 13），也是千兆网卡，两个网卡的 IP 地址也在同一网段（图中显示的是 IPv6 地址，实际也都在 192.168.1.0 网段），但两个网卡都支持 RSS，不支持 RDMA，这样多通道也是可以用的。

在服务器上建立磁盘阵列（我是建的 RAID5 哦），建立共享目录，然后在客户端上通过映射网络驱动器访问共享目录即可，由于要使用多通道，因此最好直接使用 “\\服务器主机名\共享名称” 这种形式（不要直接指定服务器上的某个 IP 地址）。

客户端中连接上共享目录之后，就可以在客户端的 PowerShell 中运行 Get-SmbMultichannelConnection 命令查看 SMB 连接是否使用了多通道：

从上图可以看到详细的 SMB 连接信息，也可以明显的得出客户端到服务器的连接已经启用了多通道（不同的客户端 IP 地址对应不同的服务端 IP 地址，从客户端和服务端的 Interface Index 网卡序号也可以看出）。另外虽然客户端网卡是支持 RSS 的，但由于服务端并不支持，因此 SMB 连接仍然未启用 RSS，当然 RDMA 就更没有启用了。

下面就可以用测试软件进行读写测试了，测试过程中可以分别看客户端和服务器上的网卡占用情况，就可以看出 SMB 3.0 多通道已经发挥作用（两个网卡都有读写产生的流量的）：

接着就可以测试容错功能是否有用了，在读写测试过程中，拔掉客户端或服务器的一根网线，可以看到对测试过程没有影响，读写可以继续进行。由本测试可以看到，Windows Server 2012 中的 SMB 3.0 多通道基本可以实现我们需要的类似负载平衡的目的，而且多通道在一般情况下完全不需要用户进行配置，Windows 会自动选择类型和速度完全一致的网卡自动进行多通道匹配。

参考链接：

http://blogs.technet.com/b/josebda/archive/2012/06/28/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0.aspx

这是一篇受密码保护的文章，您需要提供访问密码：

密码：

这是一篇受密码保护的文章，您需要提供访问密码：

密码：

最近需要使用 Symantec Backup Exec、NetBackup 等备份软件测试磁带库，而且 Backup Exec 中已经自带了很多的磁带和磁带库的驱动，但是这些驱动没法独立出来用。特别是在新的 Windows 系统上，如果 Backup Exec 备份软件无法安装，而又找不到磁带驱动，这时就需要专门的 Symantec 的磁带驱动集了。

Symantec 官方网站上有最新版本的 Tape Device Drivers 更新程序，例如：

http://www.symantec.com/business/support/index?page=content&id=TECH173790

这个是 Symantec Backup Exec 2010 R3 版本的最新磁带驱动集。

下载之后，你会发现这个更新程序必须在安装了其对应版本的备份软件之后才能运行，不同远程安装到别的机器上，这多少显得非常不便。为此我从 Symantec 官网最新版本的 Tape Device Drivers 程序中导出了所有的驱动和安装程序并打包，此包可以在没有安装 Symantec 软件的情况下，通过设备管理器直接找到解压缩的目录进行磁带驱动安装。如果安装了 Symantec 备份软件，你也可以直接用包中的 tapeinst.exe 程序自动安装更新磁带的驱动。

做这个驱动集合包的步骤也很简单，解压缩 Symantec 安装程序，然后从中得到 Data.cab 之类的压缩包并解压缩（新版本的安装程序中可能是 msp 类型的数据文件，可以用 Universal Extractor 之类的软件进行解压）。解压缩之后会看到一堆文件名很长的文件，例如：F1078_testfile.sy_.1B15BB01_8E2D_4A12_A3E6_175864F3EF67。

实际上这种长的文件是压缩过的驱动程序（原文件名：testfile.sys），只不过文件名上加了点处理，为此我写了个非常简单的脚本进行自动遍历文件并解压缩：

#!/bin/sh
# extract symantec tape device drivers from its MSI file
# file name form: F1078_testfile.sy_.1B15BB01_8E2D_4A12_A3E6_175864F3EF67"

IND="tapedrvs"
mkdir $IND

for j in `ls *`; do
	# get real file name in full file name
	ONAME=`echo $j | awk '{print substr($0,7,length($0)-43);}'`
	# determine whether file is compressed
	EXNAME=`echo $ONAME 2>/dev/null | awk -F "." '{if (substr($0,length($0),1)=="_" && NF>1) {print $NF;}}' 2>/dev/null`

	if [ "x$ONAME" = "x" ]; then
		continue
	fi

	if [ "x$EXNAME" != "x" ]; then
		# try to fix prefix name for some common file types
		NNM=""
		if [ $EXNAME = "CF_" ]; then
			NNM="CFG"
		elif [ $EXNAME = "cf_" ]; then
			NNM="cfg"
		elif [ $EXNAME = "dl_" ]; then
			NNM="dll"
		elif [ $EXNAME = "ex_" ]; then
			NNM="exe"
		elif [ $EXNAME = "in_" ]; then
			NNM="inf"
		elif [ $EXNAME = "sy_" ]; then
			NNM="sys"
		elif [ $EXNAME = "tt_" ]; then
			NNM="ttf"
		elif [ $EXNAME = "vs_" ]; then
			NNM="vsd"
		fi

		if [ -z "$NNM" ]; then
			echo "Unknown prefix of $ONAME in $j"
		else
			# use expand to extract file
			NNM=`echo $ONAME | sed 's/'$EXNAME'$/'$NNM'/g'`
			expand $j $IND/$NNM
		fi
	else
		cp $j $IND/$ONAME
	fi
done

这个脚本用到了 Windows 下的命令，因此需要在 Windows 下通过 Mingw 或者 Cygwin 之类的类 Linux shell 环境来运行。此脚本已在 Symantec 几个不同版本的 Backup Exec、NetBackup 备份软件的 Tape Device Drivers 包下验证过。

脚本会自动判断遍历到的文件是否是压缩的（压缩的文件扩展名名是以下划线结尾的，例如 test.exe 压缩后变为 test.ex_），如果是压缩的，则尝试自动修改后缀名，并通过 Windows 自带的 expand 命令将压缩的文件解压缩到指定的目录中（压缩的文件名 [test.ex_] 变换为正常的文件名 [test.exe]），如果没有识别到压缩文件类型，脚本会将压缩文件名和上面的完整文件名打印输出方便用户手工处理。如果遍历到的文件不是压缩的，那直接拷贝到指定的目录中（文件名也变换为正常的文件名）。

我已经打包好的 Symantec 磁带驱动集可以在这里下载：

http://miseal.googlecode.com/files/symantec-tape-drv-v1.0.7z

PS：

如果有的磁带未找到驱动，但确认 Symantec 可以支持，你可以自己修改解压缩出来的 vrtstape.inf 配置文件将自己的磁带设备信息加进入。另外 extract-symantec-driver 脚本也已经在压缩包中。这个驱动集主要是方便自己测试使用的，如果有任何问题欢迎指正哦。

Windows Server 2012 （之前的名字就是 Windows Server 8）即将到来，近日看到原来 Windows Server 8 中新增的 SMB 2.2 文件共享协议也有了新的官方名称：SMB 3.0，看看这个介绍说明：

http://blogs.technet.com/b/windowsserver/archive/2012/04/19/smb-2-2-is-now-smb-3-0.aspx

SMB 3.0 相对于 Windows Server 2003 以及以前的操作系统中的 SMB 1.0 协议增加了很多新的特性：

• 精简 SMB 1.0 中繁多的命令，减少 ACK 提高效率；
• 支持流水线机制，可以在上一个 SMB 命令未完成之前发新的命令；
• 支持符号链接，支持更大的文件块大小提高大块文件读写的性能；
• 更好的 oplock 机制；
• 更像真正的文件系统，原来不能安装在 SMB 共享中的程序（例如：SQL Server）也可以使用了；
• 支持通过 RDMA（Remote Direct Memory Access） 远程直接访问数据提高在 Infiniband 等环境下的性能；
• 多通道支持，通过多网络通道提高性能，而且支持错误容忍和集群。

刚好旁边有两张 Mellanox 的 Infiniband 卡，顺便就来看看 SMB 3.0 over RDMA 的实际读写性能怎么样咯。由于 SMB 3.0 只有 Windows Server 8 或者 Windows Server 2012 才支持，因此用 Windows Server 8 的测试 ISO 安装并拷贝了一份系统（服务器和客户端都必须支持 SMB 3.0）。

测试环境

服务器：

Intel S5500BC 服务器主板；
Intel Xeon E5506 CPU * 1；
Kingston DDR3 1066 4G 服务器内存 * 1；
Mellanox MHQH29B ConnectX®-2 系列 32Gbps Infiniband 卡（PCI-E x 8 插槽）；
Adaptec RAID 51645 PCIe SAS RAID卡；
WD WD10EVDS 1TB SATA 监控硬盘 * 16；
Windows Server 8 Beta Datacenter Build 8250 64位中文版；
IPoIB 网卡 IP 地址：192.168.3.196（MTU：4092）

客户端：

TYAN S7002 服务器主板；
Intel Xeon E5506 CPU * 1；
Kingston DDR3 1066 2G 服务器内存 * 1；
Mellanox MHQH19B ConnectX®-2 系列 32Gbps Infiniband 卡（PCI-E x 16 插槽）；
Windows Server 8 Beta Datacenter Build 8250 64位中文版；
IPoIB 网卡 IP 地址：192.168.3.172（MTU：4092）

其它环境：

由于没有 Infiniband 交换机，故测试时服务器和客户端的 Infiniband 卡通过 Mellanox MCC4Q30C-003 QSFP 线缆直连，而且客户端的 Infiniband 卡只有一个接口，所以也只测试了单口的性能，没有测试 SMB 3.0 多通道下的性能。

测试软件：

IBM Tivoli SANergy（测试大块文件连续读写）；
Iometer（测试大块文件并发读写）；
NetPIPE（测试 IPoIB （IP over Infiniband） 的纯粹网络性能）；
Mellanox 驱动程序中的 IB Tools（启动 SM 并测试纯粹 Infiniband 性能）

测试步骤及结果

安装 Mellanox Infiniband 驱动程序

虽然 Windows Server 8 中已经自动 Mellanox Infiniband 的驱动，但为了更新 firmware 并能使用上软件 SM（没 Infiniband 交换机滴说 -_-#），必须更新官方的驱动，到下面的网址下载新驱动：

http://www.mellanox.com/content/pages.php?pg=products_dyn&product_family=129&menu_section=34

安装 Mellanox OFED for Windows Server 2012，建议安装时按照下面的提示更新卡的 firmware 以免带来不必要的问题：

安装完成之后重启服务器和客户端，你会发现 “网络连接” 里已经有了 Mellanox 的 IPoIB 网卡，但是是 “未连接” 的状态，因为 Infiniband 网络里还没有配置 SM（Subnet Manager）。

先来简单了解下 Infiniband 的 Subnet Manager：

Infiniband（IB） 网络中需要使用 Subnet Manager（SM）来初始化 IB 硬件并允许其在 IB 架构中通信。每个 IB 子网必须有至少一个 SM，并且每个 SM 在 IB 架构中要有清楚的 ID。IB 架构就包含已经定义好的子网。IB 交换机和 IB 卡一样有自己的 GUID，主机适配卡（HCA）的端口被称为 port GUID，当一个 HCA 或者它的端口需要与子网中的另一个进行通信就需要分配网络地址，这些网络地址被称为 LID，而 IB 中的 SM 就负责为子网中的成员分配 LID，LID 只是对子网而言的，而 GUID 则是对整个 IB 架构中所有子网相同的。

IB 交换机一般就可以充当 SM 的角色，对于我这没有 IB 交换机的环境，幸好咱们还是有穷人的方法的，使用免费的 OpenSM 软件可以让两个机器中的任意一台做软件 SM。

在服务器中启用 OpenSM

OpenSM 在安装 Mellanox 驱动程序时已经自带，下面会用到的 ibstat、ibnetdiscover、ibping 等命令属于的 Mellanox IB Tools 也在安装驱动时一并安装了，里面包含了一堆实用的 IB 调试工具哦。

打开 Windows Server 8 中默认就自带的 Windows PowerShell，输入下面的命令进行安装，有关 Windows Server 8（2012）的 PowerShell 帮助信息请猛击 [这里]：

如图所示，先用 sc query opensm 命令查询 OpenSM 服务是否安装了。如果没有安装就使用 PowerShell 中的 New-Service 命令创建 OpenSM 服务并设置为开机自动启动，服务路径在 Mellanox 驱动安装路径下。

最后运行 Start-Service OpenSM 命令启动 OpenSM 服务，启动成功之后 Mellanox IPoIB Adapter 网卡的状态就变为 “已连接” 了哦。

在服务器和客户端中分别给 IB 网卡配置固定的 IP 地址，假设服务器 IP 地址为 192.168.3.196，客户端 IP 地址为 192.168.3.172。

在设备管理器或者网络连接中 IB 网卡的高级属性中可以看到 IB 网卡的详细信息：

其中可以看到 PCI-E 插槽的速度，Infiniband 卡型号，MAC 地址，IP地址，连接速度（本次测试中我用到的 IB 卡的速度就是 32Gbps 的哦）等信息。

检查 Infiniband 连接

在任意一台主机上运行 ibstat 命令可以看到本机的 IB 端口状态，其中包括 HCA 卡上不同端口的连接状态、GUID、SM LID 等信息：

运行 ibstat -p 命令可以只查看本机的 IB 端口 GUID 列表。

同样在 PowerShell 中运行 ibnetdiscover 命令检查是否能看到连接到本机的其它 IB 主机：

可以看到输出中除了自己（WIN-31E0THJOKV3 主机）之外还有客户端（WINSVR8-FULL 主机），这里也能看到各自 IB 端口的 GUID 哦（分别为 2c903000d2031 和 2c903000dcf23）。

通过 ibnetdiscover 知道对方的 GUID 之后就可以使用 ibping 命令 PING 对方主机的 GUID 能是否能连通：

可以看到普通 ping 命令类似的输出，能看到正确的响应时间，证明 IB 网络已经通啦。

测试纯粹 Infiniband 性能

我们先来测试下不走 IP 协议情况下纯粹的 Infiniband 的性能，使用 Mellanox IB Tools 中的工具可以完成此测试，同样都在 PowerShell 中完成。

在服务器中运行 ib_read_bw 命令（不加任何参数），在客户端中运行 ib_read_bw 192.168.3.196 开始进行 Infiniband 读带宽的测试（192.168.3.196 为服务器的 IB 网卡的 IP 地址）。类似的使用 ib_write_bw 命令可以测试写带宽的性能。

可以看到读带宽为 2275.69 MB/s，写带宽为 2850.94 MB/s，这个速度已经和 32Gbps 的 IB 理论连接速度有点接近了，算是能满足要求了。

再来看看纯粹 Infiniband 的读写延迟，使用 ib_read_lat 和 ib_write_lat 命令进行测试，使用方式和上面的类似。

可以看到读延迟为 2.40 微秒，写延迟为 1.44 微秒，这个表示还是比较令人满意的。 ^_^

测试 IPoIB 的纯粹网络性能

看到了上面不错的纯粹 Infiniband 性能数据，对 IPoIB 的表现有点期待了。

刚开始没找到比较好的 Windows 下的 IPoIB 测试软件，就先直接用原来一直用的 Windows 下的 iperf 测试软件来测试 TCP 连接时的纯粹网络性能了。

• 做 iperf 服务端的机器运行：iperf -s -w 1m（指定测试时的 TCP window 大小为 1MB）；
• 做 iperf 客户端的机器运行：iperf -c 192.168.3.196 -w 1m -t 30（假设 192.168.3.196 为 iperf 服务器机器的 IB 网卡的 IP 地址，指定测试时的 TCP window 大小为 1MB，持续 30 秒钟写数据）。

iperf 的最终测试结果如下：

SMB 服务器做 iperf 的服务端：7.29 Gbps
SMB 客户端做 iperf 的服务端：5.48 Gbps

有点不满意这结果，后来终于找到一个比较好的 IPoIB 测试软件：NetPIPE，NetPIPE 可以实现协议无关的测试，支持 RDMA、IPoIB、TCP/IP 等。NetPIPE 软件虽然也是 Unix 系统下的，但已经有热心的网友将其 TCP（IPoIB）版的程序 NPtcp 稍作修改移植到 Windows 上了。

有关 NetPIPE 的介绍请参考其官网：http://www.scl.ameslab.gov/netpipe/

NPtcp 的 64 位和 32 位 Windows 移植版本我已经搬运回来，到下面的网址下载即可（Windows Server 8 只有 64 位的就用其 64 位版本 NPtcp64.exe 了）：

http://miseal.googlecode.com/files/NPtcp-windows.zip

NetPIPE 使用起来很简单：

• 做服务端的机器不带任何参数运行 NPtcp64；
• 做客户端的机器上运行 NPtcp64 -h 192.168.3.196 即可得到测试结果。

NetPIPE 在测试时会从 1 开始一直往上增加网络读写操作的块值。

IPoIB 的纯粹网络性能测试结果如下图所示：

上图的测试结果为 SMB 服务器做 NetPIPE 服务端时的结果，当网络读写的块值达到 1048576 也即 1MB 时，网络性能达到最高峰 7686.283 Mbps，在 1MB 读写块值的旁边性能会有所下降。

SMB 客户端做 NetPIPE 服务端时的网络性能与上面差不多一直，这里就不再列出来了。

从 NetPIPE 的测试结果来看，其还算是符合 iperf 的测试结果的，但与纯粹 Infiniband 的速度相差的确实在太多（有 3~4 倍了），看来 IPoIB 的性能损失确实是比较大的。

确认 SMB 3.0 over RDMA 是否可用

为了最大程度上体现 SMB 3.0 over RDMA 的性能，这里我们在检查 RDMA 是否可用的基础上又检查了 RSS（Receive Side Scaling 接收端缩放处理数据）、NetworkDirect 等是否可用，这样如果你的硬件环境充足，完全可以让 SMB 3.0 的多通道测试正常跑起来。如果你只需要和我一样测试 SMB 3.0 over RDMA，那可以忽略 RSS 之类的检查。

简单说下 SMB 3.0 的多通道需要的条件：

• 两台计算机必须都为 Windows Server 8 或者 2012；
• 必须都有多个网卡，网卡速度需要一致；
• 其中一个或多个网卡支持 RSS 或者 NIC Teaming（网卡绑定）或者 RDMA。

首先在 PowerShell 下通过 Get-NetAdapter 命令得到所有网卡列表，输出中包含网卡序号、型号、连接速度、连接状态、MAC 地址等信息：

通过 Get-NetOffloadGlobalSetting 命令检查 Network Direct 设置是否已启用：

Network Direct 是一种从 Windows HPC Server 2008 系统开始引入的新的低延迟 RDMA API，一般默认都是启用的，SMB 3.0 over RDMA 就是基于 Network Direct API 来实现的。

通过 Get-NetAdapterRDMA 命令检查本机的网卡上是否已启用 RDMA：

从上面可以明显的看出来此机器上的两个 IB 端口都已经默认启用 RDMA。

通过 Get-NetAdapterRSS 命令检查本机的网卡上是否已启用 RSS：

已启用 RSS 的网卡的 IndirectionTable 中会有有效的信息，由于这台服务器上有一个 IB 网卡没有接线缆，因此上面的 IB 网卡没有启用 RSS。

通过 Get-SmbServerConfiguration 和 Get-SmbClientConfiguration 命令分别在服务器和客户端上检查 SMB 多通道是否已启用：

SMB 多通道默认在系统中都是启用的，无特殊原因都不需要禁用。

在客户端中用 Get-SmbClientNetworkInterface 命令检查用于 SMB 的网卡列表是否启用 RSS 和 RDMA：

从上面的输出中可以看到客户端中的第一个网卡（即 32Gbps 的 IPoIB 网卡）已经启用 RSS 和 RDMA，而已经接了网线的最后两个千兆网卡则只启用了 RSS 但 RDMA 没有作用（本身硬件不支持哦）。

类似的可以在服务器中用 Get-SmbServerNetworkInterface 命令检查用于 SMB 的网卡列表是否启用 RSS 和 RDMA：

可以看到 IPoIB 网卡的 RSS 和 RDMA 已启用，两个千兆网卡中一个 RSS 已启用，而另一个则不支持。

由于本次主要测试目的在 RDMA 测试，多通道 RDMA 暂时也没有条件，最终可以在服务器上用 netstat -xan 命令查看 SMB RDMA 端口是否已经在正确的监听处理了：

通过输出可以看到在服务器上，系统已经在 445（SMB 服务端口）上处理 RDMA 数据了。

测试 SMB 3.0 over RDMA 性能

此时环境已经全部准备好了，在服务器上用 16 个硬盘建 RAID0，启用所有缓存以求达到最高性能。接着在创建好的 RAID0 磁盘阵列上建 NTFS 分区，并建立 SMB 文件共享。

首先在服务器上使用 IBM Tivoli SANergy 软件测试 RAID0 磁盘阵列本地连续读写的性能：

1MB 连续写性能：735.80 MB/s
1MB 连续读性能：956.77 MB/s

与预期的比较接近，然后在客户端上通过映射网络驱动器映射 SMB 共享，可以在客户端 PowerShell 下使用下面的命令确定 SMB 是否确实使用 RDMA：

Get-WinEvent -LogName Microsoft-Windows-SMBClient/Operational | ? Message -match "RDMA"

这条命令会在事件日志中查找 SMBClient 的包含 “RDMA” 字符串的日志并显示出来。

你也可以直接打开 “事件查看器”，然后打开 “应用程序和服务日志” - “Microsoft” - “Windows” - “SMBClient” 子项，在其 “Operational” 事件日志中可以找到 SMB 客户端连接时的日志，如果使用了 RDMA，会很容易看出来，如下图所示：

图中就表示从本机连接 SMB 服务器 192.168.3.196 时使用了 RDMA。

确认客户端和服务器之间的 SMB 连接使用 RDMA 之后，就可以开始测试了。首先使用 IBM Tivoli SANergy 软件测试下大块文件的连续读写，结果如下：

1MB 连续写性能：501.98 MB/s
1MB 连续读性能：626.02 MB/s

和刚才的 RAID0 本地读写速度相比，读写性能损失又有不少，但勉强能接受。

贴上连续读写时 SMB 服务器的 CPU 占用图：

从测试时的 CPU 占用曲线来看，SMB 服务器的 CPU 占用在 3% ~ 5% 之间，RDMA 的效果还是比较明显的。

下面则是用 Iometer 软件来看看连续并发读写情况下的性能：

1MB 连续并发写性能：958.81 MB/s
1MB 连续并发读性能：784.95 MB/s

这个好歹能和纯粹的 IPoIB 网络性能接近了，SMB 3.0 over RDMA 的测试可以交差了。

这是并发读写时 SMB 服务器的 CPU 占用图：

客户端 Iometer 在做并发读写测试时，SMB 服务器的 CPU 占用在 8% ~ 11% 之间，也还是非常不错的。

Windows Server 8 上的 Infiniband 和 SMB 搞定，至此测试结束。

总结

从结果来看，Windows Server 8 上 Mellanox 的 Infiniband 卡本身的性能和延迟还是比较不错，但 IPoIB 的性能确实是相对比较差，但和上次在 Linux 上 IPoIB 的结果来看表现还是略胜一筹，而 SMB 3.0 over RDMA 对比上次在 Linux 上的 SRP 的测试性能也是比较接近的，总体看来微软新推出的 SMB 3.0 还是比较值得期待的（PS：微软已经为嵌入式 Linux 提供 SMB 2.0 的工具和 SDK 了）。

参考链接：

• http://www.mellanox.com/pdf/whitepapers/WP_Deploying_Windows_Server_IB.PDF
• http://technet.microsoft.com/en-us/library/dd391826(v=ws.10)
• http://blogs.technet.com/b/josebda/archive/2012/05/14/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0.aspx

本次性能测试为笔者为 SMB 3.0 over RDMA 特意做的，没有考虑到通用性，文中有任何错误或问题欢迎指正咯 ^_^

微软最新的 Windows Server 8（现在已改名为 Windows Server 2012，坑爹的命名，汗下）中支持了微软引入的新文件系统 ReFS 用于替换存在了 N 年了的 NTFS 文件系统。大家可能依稀还记得当前 Longhorn（其实就是后来的 Vista 操作系统的开发代号） 操作系统发布时传闻要引入的新文件系统 WinFS 被阉割的消息，到了 2012 年终于推出了新文件系统 ReFS。

ReFS 全名为 Resilient File System（弹性文件系统），按照微软官方的说明，ReFS 相对 NTFS 主要的改进有：

1、改进磁盘上的数据结构，ReFS 也跟着主流文件系统的脚步使用 B+ 树来存储元数据和实际数据了，文件大小、卷大小等的限制也还是 64 位，元数据和实际数据被以类似关系数据库形式的表组织起来，文件名和路径长度的限制也扩大为 32KB 的 Unicode 字符串；
2、元数据增加校验和，增强数据的验证和自动更正处理，支持 COW 实现可靠磁盘数据更新；
3、扩大卷大小、文件大小、文件夹大小；
4、数据条带提高性能，并支持错误容忍；
5、可以在不同的计算机间共享存储池以增强容错性和负载平衡；
6、也是非常重要的，对 NTFS API 及使用方式上的很大程度上的兼容，包括 ACL、符号链接、挂载点、oplock 等，但也有一些 NTFS 的特性例如 文件压缩、硬链接、用户磁盘配额 等没有被支持。

有关 ReFS 的详细原理及说明请参考这个 MSDN 的 blog：

http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx

需要注意的是 Windows 7 及之前的系统都不支持 ReFS，而且 Windows 8 似乎也只有服务器版本才支持。借着前几天下载安装的 Windows Server 8 测试版本系统笔者就先简单测试下 ReFS 相对 NTFS 的性能，由于我这实际应用时以顺序读写为主，先做顺序读写性能对比。

测试环境：

Intel S5500BC 服务器主板；
Intel Xeon 5506 CPU * 1；
Kingston DDR3 1066 4G 服务器内存 * 1；
Adaptec RAID 51645 PCIe SAS RAID卡；
WD WD10EVDS 1TB SATA 监控硬盘 * 16；
Windows Server 8 Beta Datacenter Build 8250 64位中文版；
Iometer 1.1.0-rc1 Windows 64位版本

16 个 1TB 的 SATA 盘建 RAID0，RAID0 的块值为 256KB，并启用 read 和 write cache。然后在 Windows Server 8 中的磁盘阵列设备上分别建 2TB 大小的简单卷，格式化为 NTFS 和 ReFS，分别测试其连续读写性能。

在磁盘管理里新建分区格式化时就可以看到 ReFS 的选项：

测试结果：

从测试结果可以看到，ReFS 相对 NTFS 来说在小一些的块值的连续读写上并没有什么优势，而在 RAID0 的整个 stripe 条带大小（256KB * 16 = 4MB）的读写性能上则确实比 NTFS 有一点改进。

另外说下 ReFS 暂时的不足之处：

1、Windows 8 虽然已经支持 ReFS，但并没有 NTFS 和 ReFS 之间转换的工具，你如果需要从 NTFS 切换到 ReFS，暂时只能手工中转拷贝了；
2、不支持从 ReFS 引导启动系统；
3、可移动磁盘或者 U 盘之类的设备不能使用 ReFS；
4、不支持文件压缩和用户磁盘配额，虽然这两个用的可能不是非常多，但还是有点不可想象；
5、NTFS 中原来支持的扩展属性 ReFS 也不再支持，有一些软件会依赖这个，感觉会有些不便。

总之现在看起来微软新引入的 ReFS 并没有像 ZFS 那样的新文件系统（支持 RAID-Z、原生快照、128位文件系统等特性）那样吸引人，如果要吸引用户转移到 ReFS 感觉还是任重道远，不知道 Windows Server 2012 最终版本中的 ReFS 到底有何改善。

本文章中介绍的只是测试了连续读写的性能，ReFS 重点支持的容错等功能下次有机会时再来测试，文中有任何问题欢迎指正咯。 ^_^