一种多级缓存的网络文件系统管理方法与流程

1.本公开涉及计算机系统软件技术领域，尤其涉及一种多级缓存的网络文件系统管理方法。


背景技术：

2.随着网络文件系统在嵌入式装备中的应用和发展，其提供的访问节点规模大幅增加。在网络文件系统中，基于标准nfsv3协议，通常没有缓存管理或者只采取了单级缓存管理来提升客户端读写性能。此种方式下，针对机载环境下频繁访问不经常更改的文件的场景，应用软件的读写时间开销仍然很大，无法满足机载领域在支持高性能等方面的要求，因此需要采用多级缓冲管理技术来提升网络文件系统性能。


技术实现要素：

3.有鉴于此，本公开实施例提供一种多级缓存的网络文件系统管理方法，至少部分解决现有技术中存在的问题。利用多级缓存技术，减少客户端与服务器的同步交互次数，提升机载系统的读写性能；同时基于rsync算法高效实现服务器和客户端缓存文件数据的增量传输，在一定程度上保证服务器和客户端缓存文件数据的正确性和一致性。
4.为了实现上述目的，本发明提供如下技术方案：
5.一种多级缓存的网络文件系统管理方法，应用于客户端，所述方法包括：
6.步骤1：应用软件向客户端请求文件，客户端搜索本地缓存；
7.步骤2：若客户端的本地缓存未命中，则客户端向服务器读取该文件，并获取最后一次修改该文件的时间属性，将该文件返回应用软件，同时将该文件和最后一次修改该文件的时间属性保存至本地缓存；
8.若客户端的本地缓存命中，则客户端向服务器获取最后一次修改该文件的时间属性，与客户端缓存记录表中该文件的最后一次修改该文件的时间属性进行对比，当对比结果一致，则将本地缓存中该文件返回至应用软件；当对比结果不一致，则：客户端向服务器读取该文件，并获取最后一次修改该文件的时间属性，将该文件返回应用软件，同时将该文件和最后一次修改该文件的时间属性保存至本地缓存。
9.进一步地，所述步骤2中：客户端的本地缓存未命中时的执行策略包括如下步骤：
10.步骤2.1：应用软件向客户端请求文件，客户端从服务器读取该文件，并基于nfsv3协议中的stat功能从服务器获取最后一次修改该文件的时间属性；
11.步骤2.2：客户端将获取的文件放入客户端的内存缓存区，并将读取的内容返回给应用软件；
12.步骤2.3：客户端将获取的文件写入客户端的本地文件系统缓存区；
13.步骤2.4：客户端将获取的最后一次修改该文件的时间属性记录在所述本地文件系统缓存区的缓存记录表中。
14.进一步地，所述步骤2中：客户端的本地缓存命中时的执行策略包括如下步骤：
15.步骤3.1：基于nfsv3协议中的stat功能从服务器获取最后一次修改该文件的时间属性；
16.步骤3.2：客户端利用服务器返回的最后一次修改该文件的时间属性，与所述本地文件系统缓存区的缓存记录表中该文件最后一次修改时间属性进行比较；
17.步骤3.3：如果该文件最后一次修改时间属性一致，客户端直接从所述本地文件系统缓存区中读取文件，返回给应用软件。
18.进一步地，所述步骤3.3中：如果文件最后一次修改时间属性不一致，将服务器与客户端该文件进行同步，完成后客户端再将文件返回给应用软件，同时将该文件写入所述本地文件系统缓存区。
19.进一步地，所述步骤3.3中：如果文件最后一次修改时间属性不一致时还包括：基于nfsv3协议中的stat功能从服务器获取最后一次修改该文件的时间属性，更新所述本地文件系统缓存区的缓存记录表中该文件的最后一次修改时间属性。
20.进一步地，采用rsync算法进行服务器与客户端文件的同步。
21.由于机载环境下需要频繁访问不经常更改的文件，而基于nfsv3协议的网络文件系统通常没有缓存管理或者只采取了单级缓存管理，应用软件的读写时间开销仍然很大，因此本发明提出了一种多级缓存的网络文件系统管理方法来提升应用读写性能。本方法的特点包括：由客户端、服务器两部分组成，缓存管理应用于客户端。其有益效果在于：
22.(1)利用多级缓存技术，减少客户端与服务器的同步交互次数，尤其是针对频繁访问但却未更改的文件，直接从本地文件系统读取，可以提升系统的读写性能；
23.(2)基于rsync算法高效实现服务器和客户端缓存文件数据的增量传输，在一定程度上保证服务器和客户端缓存文件数据的正确性和一致性，同时也提升了效率，最终，网络文件系统能满足机载领域在支持高性能等方面的要求。
附图说明
24.为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
25.图1为本发明的多级缓存的网络文件系统管理方法结构示意图；
26.图2为本发明中本地无缓存方法组成图；
27.图3为本发明中本地缓存未发生变化方法组成图；
28.图4为本发明中本地缓存发生变化方法组成图；
29.图5为本发明实施例1中方法结构示意图；
30.图6为本发明实施例2中方法结构示意图。
具体实施方式
31.下面结合附图对本公开实施例进行详细描述。
32.以下通过特定的具体实例说明本公开的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本公开的其他优点与功效。显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。本公开还可以通过另外不同的具体实施方式加以实
施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本公开的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。
33.要说明的是，下文描述在所附权利要求书的范围内的实施例的各种方面。应显而易见，本文中所描述的方面可体现于广泛多种形式中，且本文中所描述的任何特定结构及/或功能仅为说明性的。基于本公开，所属领域的技术人员应了解，本文中所描述的一个方面可与任何其它方面独立地实施，且可以各种方式组合这些方面中的两者或两者以上。举例来说，可使用本文中所阐述的任何数目个方面来实施设备及/或实践方法。另外，可使用除了本文中所阐述的方面中的一或多者之外的其它结构及/或功能性实施此设备及/或实践此方法。
34.还需要说明的是，以下实施例中所提供的图示仅以示意方式说明本公开的基本构想，图式中仅显示与本公开中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。
35.另外，在以下描述中，提供具体细节是为了便于透彻理解实例。然而，所属领域的技术人员将理解，可在没有这些特定细节的情况下实践所述方面。
36.如图1所示，本公开实施例提供一种多级缓存的网络文件系统管理方法，由客户端、服务器两部分组成，缓存管理应用于客户端。所述方法包括：
37.步骤1：应用软件向客户端请求文件，客户端搜索本地缓存；
38.步骤2：若本地缓存未命中，表示首次加载和读取文件，此种情况下客户端本地并无文件缓存，具体处理包括以下步骤，如图2所示：
39.步骤2.1：应用软件向客户端请求文件，客户端从服务器读取文件，并基于nfsv3协议中的stat功能从服务器获取最后一次修改该文件的时间属性；
40.步骤2.2：客户端将获取的文件放入客户端的内存缓存区，并将读取的内容返回给应用软件；
41.步骤2.3：客户端将获取的文件写入客户端的本地文件系统缓存区。
42.步骤2.4：客户端将获取的最后一次修改该文件的时间属性记录在所述本地文件系统缓存区的缓存记录表中。
43.若本地缓存命中，此种情况下客户端本地有文件缓存，具体处理包括以下步骤，如图3所示：
44.步骤3.1：基于nfsv3协议中的stat功能从服务器获取最后一次修改该文件的时间属性；
45.步骤3.2：客户端利用服务器返回的最后一次修改该文件的时间属性，与所述本地文件系统缓存区的缓存记录表中该文件最后一次修改时间属性进行比较；
46.步骤3.3：如果该文件最后一次修改时间属性一致，客户端直接从所述本地文件系统缓存区中读取文件，返回给应用软件。
47.如果文件最后一次修改时间属性不一致，将服务器与客户端该文件进行同步，完成后客户端再将文件返回给应用软件，同时将该文件写入所述本地文件系统缓存区。
48.如果文件最后一次修改时间不一致，说明文件版本已发生变化，如图4所示，则采用rsync算法高效实现服务器与的客户端文件的同步。基于nfsv3协议中的stat功能从服务器获取最后一次修改该文件的时间属性，更新客户端本地缓存记录表中该文件的最后一次修改时间。
49.下面结合附图和实施例对本发明做进一步详细描述。
50.实施例1
51.(1)典型的运行环境
52.一个分布式航电平台，包括模块1、模块2、模块3三个物理节点，底层使用fc网络通信，本地文件系统使用fat32，每个物理节点上部署分区操作系统，具有调试串口。
53.模块1、模块2部署网络文件系统客户端，模块3部署网络文件系统服务器。
54.(2)配置以及配置数据的生成和加载
55.模块1配置节点标识为1，角色为clnt，本地缓存目录为本地文件系统b:\\clnt1\\下。
56.模块2配置节点标识为2，角色为clnt,本地缓存目录为本地文件系统b:\\clnt2\\下。
57.模块3配置节点标识3，角色为serv。
58.配置数据生成和加载方式：为三个节点生成一份配置数据nfscfg.dat,加载到模块1、模块2和模块3的本地文件系统a:\\下。
59.(3)应用效果
60.a.对模块1、模块2和模块3加电，模块1通过初始化接口传入节点标识1，模块2通过初始化接口传入节点标识2，模块3通过初始化接口传入节点标识3，分别从本模块的本地文件系统加载a:\\nfscfg.dat数据，并完成初始化。
61.b.模块2加载测试程序，读取一个命名为test.txt的文件,文件内容为“test ok！”，如图5所示。模块2本地文件系统中缓存管理目录b:\\clnt2\\下没有test.txt文件，因此客户端直接访问服务器读取test.txt，并访问服务器获取test.txt的最后一次修改时间，将读取内容返回给应用，同时写入本地文件系统缓存管理目录b:\\clnt2\\下，将获取的最后一次修改该文件的时间记录在本地缓存记录表中。客户端串口打印如下信息：
62.clnt read test.txt from server
63.clnt read data:testok,cnt:8
64.test.txt has been saved at b:\\clnt2\\in local fs
65.实施例2
66.(1)典型的运行环境
67.一个分布式航电平台，包括模块1、模块2、模块3三个物理节点，底层使用fc网络通信，本地文件系统使用fat32，每个物理节点上部署分区操作系统，具有调试串口。
68.模块1、模块2部署网络文件系统客户端，模块3部署网络文件系统服务器。
69.(2)配置以及配置数据的生成和加载
70.模块1配置节点标识为1，角色为clnt，本地缓存目录为本地文件系统b:\\clnt1\\下。
71.模块2配置节点标识为2，角色为clnt,本地缓存目录为本地文件系统b:\\clnt2\\
下。
72.模块3配置节点标识3，角色为serv。
73.配置数据生成和加载方式：为三个节点生成一份配置数据nfscfg.dat,加载到模块1、模块2和模块3的本地文件系统a:\\下。
74.(3)应用效果
75.a.对模块1、模块2和模块3加电，模块1通过初始化接口传入节点标识1，模块2通过初始化接口传入节点标识2，模块3通过初始化接口传入节点标识3，分别从本模块的本地文件系统加载a:\\nfscfg.dat数据，并完成初始化。
76.b.模块1加载测试程序，读取一个命名为test.txt的文件，文件内容为“test ok！”，如图6所示。模块1本地文件系统中缓存管理目录b:\\clnt1\\下缓存了test.txt文件，因此客户端访问服务器获取test.txt的最后一次修改时间，最后一次修改文件的时间与客户端本地缓存记录表中获取的相同，客户端直接从本地文件系统缓存管理目录b:\\clnt1\\读取test.txt，客户端串口打印如下信息：
77.clnt read test.txt from local fs
78.clnt read data:testok,cnt:8
79.实施例3
80.(1)典型的运行环境
81.一个分布式航电平台，包括模块1、模块2、模块3三个物理节点，底层使用fc网络通信，本地文件系统使用fat32，每个物理节点上部署分区操作系统，具有调试串口。
82.模块1、模块2部署网络文件系统客户端，模块3部署网络文件系统服务器。
83.(2)配置以及配置数据的生成和加载
84.模块1配置节点标识为1，角色为clnt，本地缓存目录为本地文件系统b:\\clnt1\\下。
85.模块2配置节点标识为2，角色为clnt,本地缓存目录为本地文件系统b:\\clnt2\\下。
86.模块3配置节点标识3，角色为serv。
87.配置数据生成和加载方式：为三个节点生成一份配置数据nfscfg.dat,加载到模块1、模块2和模块3的本地文件系统a:\\下。
88.(3)应用效果
89.a.对模块1、模块2和模块3加电，模块1通过初始化接口传入节点标识1，模块2通过初始化接口传入节点标识2，模块3通过初始化接口传入节点标识3，分别从本模块的本地文件系统加载a:\\nfscfg.dat数据，并完成初始化。
90.b.模块1加载测试程序，读取一个命名为test.txt的文件,文件内容为“test ok！”。模块1本地文件系统中缓存管理目录b:\\clnt1\\下缓存了test.txt文件，因此客户端访问服务器获取test.txt的最后一次修改时间，最后一次修改文件的时间与客户端本地缓存记录表中获取的该文件最后一次修改文件的时间不相同，说明该文件版本发生了改变，则采用rsync算法高效实现服务器与的客户端文件的同步，完成后客户端再将文件返回给应用，同时写入本地文件系统缓存管理目录b:\\clnt2\\下，将获取的最后一次修改该文件的时间记录在本地缓存记录表中。客户端串口打印如下信息：
91.clnt read test.txt from server
92.clnt read data:testok,cnt:8
93.test.txt has been saved at b:\\clnt2\\in local fs
94.以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以权利要求的保护范围为准。