周家劲，谢俊峰，胡晓勤，谢卓伟

（1.四川大学网络空间安全学院，成都 610200；2.成都云祺科技有限公司，成都 610041）

0 引言

传统的文件系统如NTFS、Ext4实现在内核态，以物理磁盘作为存储介质；在内核开发新的文件系统技术门槛较高，设计较为困难。FUSE（file system in userspace）提供一种面向类Unix操作系统的软件接口，内核组件与VFS（virtual file system）交互，使得用户无需编辑内核代码即可创建自己的文件系统，在类Unix操作系统端已有成熟的应用，比较知名的有GlusterFS（gluster file system）、ZFS（zettabyte file system）、SSHFS等，其他一些出于研究目的搭建的文件系统也使用了FUSE。由于Windows平台的非开源环境，开发文件系统的难度更高，用户空间文件系统的发展缓慢，FUSE底层设计面向VFS接口，Windows平台下无法使用FUSE开发易于维护的用户空间文件系统。

Dokan与WinFsp两个开源项目搭建类似FUSE的框架，可以无需编写设备驱动程序在Windows上创建除FAT或NTFS以外的新文件系统。NFS-win、sshfs-win基 于WinFsp，winSshFs基于Dokan,SftpDrive可利用ssh或nfs将远端文件系统挂载到本地网络驱动器，像访问本地文件一样访问远端文件系统。

本文提供了一种开发文件系统且不需要挂载新卷的详细设计方案，在此基础上设计并实现了一个基于文件过滤驱动的跨平台网络文件系统-CPNFS（cross-platform network file system）。CPNFS无需新建卷分配盘符，在原有卷子目录下即可虚拟一个文件系统。如图1所示，通过文件过滤驱动，监视、拦截I/O管理器下发的I/O请求包IRP（I/Orequest packet）。请求包沿设备栈向下传递，发送到卷设备的文件请求先经过文件过滤驱动。用户层遵循客户端/服务器架构，采用TCP协议进行通信。服务端可以是任意平台，客户端用户层使用内核提供的接口获取请求发送到服务端处理，实现文件请求的重定向。对比测试了CPNFS与其他远端共享文件系统在读写上的效率以及系统的兼容性，实验结果表明，CPNFS在性能与兼容性上均有优秀的表现。

图1 分层驱动

1 系统架构与设计

1.1 系统架构

如图2所示，CPNFS采用客户端/服务器端架构，客户端由用户层客户端进程CPNFS-user与内核层过滤驱动CPNFS-kernel组成。

图2 CPNFS系统框架

内核层CPNFS-kernel主体为文件系统过滤驱动，由过滤模块、控制模块与队列管理模块组成。过滤模块绑定文件系统卷，监视拦截用户层始发进程通过环境子系统下发的文件请求，将需要处理的I/O请求传递到队列管理模块。队列管理模块负责请求的出入队以及超时处理，I/O队列类型分为待处理队列、处理队列两种。控制模块通过IRP_MJ_DEVICE_CONTROL例程暴露给用户层接口，用户层利用此接口访问内核数据。

客户端用户层进程分为通信模块client、请求处理模块、过滤管理模块以及统一接口层。通信模块与服务端建立连接，发送请求报文到服务端，从服务端接收完成报文，完成报文传递给请求处理模块。请求处理模块对请求进行预处理，需要传递到远端处理的请求转换成请求报文传递给通信模块，接收完成结果后利用统一接口层将数据传递到内核。过滤管理模块维护过滤路径表，将过滤路径与远端文件系统一一对应。

服务端由通信模块server、文件管理模块以及响应模块reactor组成。通信模块维护客户端的连接，为每一个连接的客户端建立子进程收发报文，并将请求报文传递给响应模块。响应模块接收请求报文，使用用户层API对VFS层发起IO操作，将完成结果转化为完成报文传递给通信模块。文件管理模块建立客户端文件对象与本地文件描述符的映射，并保存文件的客户端独有属性。

1.2 用户文件系统接口

表1 请求处理统一接口

1.3 文件对象管理

用户层进程打开文件获得句柄，通过句柄对文件或文件夹进行操作，内核层则会创建文件对象，文件对象包含名称、安全描述符、偏移位置和引用计数等信息，句柄与文件对象一一对应，通过文件对象指针可以控制访问一个文件的打开实例。文件对象由内核组件对象管理器创建，从内核空间分配内存地址，因不同进程共享内核空间，指向文件对象的指针在不同进程上下文中可唯一指定一个文件对象。因此，重定向进程管理文件对象时，以文件对象指针数值作为键建立哈希表。

CPNFS采用了如图3所示的数据结构来管理文件对象，客户端建立以文件对象指针为键的文件哈希表，缓存文件的属性信息如文件名、安全描述符以及目录的打开状态。服务端对每一个客户端建立以文件对象指针为键的文件映射哈希表，完成客户端文件对象与服务端文件描述符的映射，同时储存文件名、文件属性stat、inode等信息，Linux下inode可以唯一标识一个文件。同时建立以inode为键的属性哈希表，缓存客户端设置的一些NTFS独有属性file_attri，所有进程共享同一个属性哈希表，此表驻留在服务端。

图3 文件对象存储方式

1.4 请求处理流程

CPNFS请求处理流程如图4所示，客户端进程与服务器端建立连接，设置过滤目录与服务器端目录建立映射，完成后客户端进程进入休眠。新的文件请求到达过滤驱动时，截获需要重定向处理的IRP，将该IRP挂起并插入待处理队列，返回PENDING状态表示请求后续异步完成。新请求入队时客户端进程唤醒，通过CTL_GET_REQUEST接口从内核队列获取请求内容，然后发送请求报文到服务端，服务端处理完成后发送完成报文到客户端，客户端通过CTL_RESPONSE_COMPLETION通知内核请求已完成并以内存映射的方式将数据传递到内核。

图4 一次IO处理流程

1.5 文件操作

（1）打开操作。当用户进程使用fopen、CreateFile等系统调用打开文件时，客户端进程发送文件名以及打开标记到服务端。服务端打开文件，建立本地文件对象与服务端文件描述符的映射，并建立文件打开列表保存已打开的文件，返回到客户端时内核完成请求，IO管理器返回句柄。

（2）读操作。当用户进程使用fread、Read-File等系统调用通过文件句柄读取文件时，客户端进程发送文件对象键值、偏移量以及读取长度到服务端，服务端通过查找文件打开列表获得文件描述符，使用服务端系统调用如pread读取文件，获得数据后返回到客户端。

（3）写操作。当用户进程使用fwrite、Write-File等系统调用通过文件句柄写文件时，客户端进程请求参数以及数据报文到服务端，服务端使用服务端系统调用如pwrite将数据写入文件。

（4）查询文件属性。当用户进程使用Get-FileInformationByHandle等系统调用查询文件属性时，客户端进程转换请求为符合服务端的请求类型，将请求发送到服务端，服务端查询文件属性后返回到客户端，客户端转换属性结构返回到内核。

（5）目录遍历。当资源管理器获取目录下的子目录或文件时，客户端进程发送目录遍历请求到服务端，服务端遍历目录返回到客户端，客户端转换格式将目录内容返回到内核。

According to above all, we can draw the calculated value of X axial force of support plates as follows:

（6）关闭操作。当用户进程调用fclose、CloseHandle等系统调用关闭句柄时，IO管理器会检查对象的引用计数是否为0，引用计数为0时表明没有用户进程或内核组件访问该文件。客户端进程发送文件对象键值到服务端，服务端关闭文件并删除文件映射表中对应项。

2 实验

2.1 实验配置

所有的实验在Vmware ESXI管理的虚拟化环境下所开启的两台虚拟机上运行，其中一台作为CPNFS的服务器，另外一台作为CPNFS的客户端。服务器端系统为CentOS 7，内核版本为Linux 3.10.0，预留2GB内存；客户端版本为Windows server 2012，内部版本为6.2.9200，预留8 GB内存。使用iperf3测试客户端到服务端的上行带宽约150MB/s，下行带宽约100MB/s。表2为测试环境的具体参数。

表2 实验环境配置

2.2 文件操作性能

本节使用标准测试工具FIO（Flexible I/Otester）测 试CPNFS、WinFsp+NFS-win、WinFsp+SshFs-win、Dokan+WinSshFs与SftpDriver在8 KB随机读写吞吐、8 KB混合随机读写吞吐以及4 MB顺序读写吞吐性能。

2.2.1 随机访问性能

测量了CPNFS与其他几种网络文件系统的8KB随机读写以及读占70%、写占30%的混合随机读写两个项目。从结果上看，CPNFS的随机读性能与WinFsp+sshfs-win接近，相对于WinFsp+NFS-win约提升40%，接近Dokan+winSshFs的2倍，是SftpDriver的2.5倍以上。CPNFS的随机写性能接近Dokan+winSshFs，是WinFsp+NFS-win的7倍以上，WinFsp+sshfs-win的4倍以上，SftpDriver的1.5倍以上，见图5。

图5 CPNFS与其他关于8 KB随机读写的性能比较

从8 KB上读占70%、写占30%的混合随机读写的结果上可以看到CPNFS的读写同时进行场景的性能均比其他四个优秀，分别约提升180%、100%、70%、30%，见图6。

图6 CPNFS与其他关于8KB混合随机读写的性能比较

2.2.2 顺序访问性能

在4 MB的顺序读上，CPNFS与WinFsp+NFS-win的性能接近，远远超过WinFsp+sshfswin与SftpDriver，是WinFsp+sshfs-win的3倍以上、SftpDriver的35倍以上，其中Dokan+win SshFs不支持大文件的顺序读。在4 MB的顺序写上，CPNFS的性能相对于WinFsp+NFS-win约提升了50%，与其他三者相比分别提升了500%、850%、1660%，见图7。

图7 CPNFS与其他关于4 MB顺序访问的吞吐性能比较

2.3 综合比较

表3总结了CPNFS与WinFsp+NFS-win在几个测试场景的性能对比，可以发现，除顺序读以外，其他场景下CPNFS的性能都比较优秀。

表3 CPNFS与WinFsp+NFS-win综合比较

3 结语

本文提出了一种基于文件过滤驱动的文件系统设计方法，实现无需挂载盘符的用户文件系统开发。该设计在内核层截获所有文件IO，保存需要处理的IO并提供统一接口供用户层实现，可在原来文件系统卷目录下虚拟文件系统。基于该设计，在Windows下设计并实现了一个跨平台的网络文件系统-CPNFS，无需新建新卷即可如访问本地文件系统一样访问远端文件系统。实验测试结果表明，CPNFS在随机读写与顺序写上，相较于其他共享文件系统方法都具有十分明显的优势。