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

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 重点支持的容错等功能下次有机会时再来测试，文中有任何问题欢迎指正咯。 ^_^