CN111241040A - 信息获取方法、装置、电子设备及计算机存储介质 - Google Patents

Abstract

本申请实施例提供了一种信息获取方法、装置、电子设备及计算机存储介质。信息获取方法包括：根据文件缓存信息读取指令，获取所述指令所指示的对象；从至少两个文件系统中，确定与所述对象对应的目标文件系统；根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息。通过本实施例提供的方案，可以以文件系统为粒度来确定文件系统中已缓存的文件对应的缓存信息，并且本方案实现简单，效率较高。

Description

信息获取方法、装置、电子设备及计算机存储介质

技术领域

本申请实施例涉及数据处理技术领域，尤其涉及一种信息获取方法、装置、电子设备及计算机存储介质。

背景技术

通常，为了能够使应用程序快速读取文件，会将部分文件预读到缓存中，当应用程序读取文件时，无需进行IO操作，直接将缓存中的文件发送至应用程序即可，从而提升文件访问时的性能。然而，为了更好地利用缓存，有时会需要确定缓存中具体包括哪些文件，每个文件占用的缓存大小等缓存信息。

但是通过现有的操作系统提供的接口，仅能够查看缓存整体的信息，例如查看缓存的整体大小等，并不能确定缓存中包括的具体文件对应的缓存信息。

因此，现有技术亟需解决的技术问题是，提供另一种能够确定已缓存的文件对应的缓存信息的方案。

发明内容

有鉴于此，本申请实施例所解决的技术问题之一在于提供一种信息获取方法、装置、电子设备及计算机存储介质，用以克服现有技术中应用程序的新业务发布不够灵活，不能适应快速变化的用户需求的缺陷。

本申请实施例提供了一种信息获取方法，其包括：根据文件缓存信息读取指令，获取所述指令所指示的对象；从至少两个文件系统中，确定与所述对象对应的目标文件系统；根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息。

本申请实施例提供了一种信息获取方法，其包括：根据文件缓存信息获取请求生成用于读取目标文件系统的文件缓存信息的读取指令；通过所述读取指令，指示所述目标文件系统所在的操作系统通过如上所述的方法，读取并返回所述目标文件系统中已缓存的文件的缓存信息；获取所述操作系统返回的所述缓存信息。

本申请实施例提供了一种信息获取装置，其包括：对象获取模块，用于根据文件缓存信息读取指令，获取所述指令所指示的对象；系统确定模块，用于从至少两个文件系统中，确定与所述对象对应的目标文件系统；缓存信息确定模块，用于根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息。

本申请实施例提供了一种信息获取装置，其包括：指令生成模块，用于根据文件缓存信息获取请求生成用于读取目标文件系统的文件缓存信息的读取指令；信息返回模块，用于通过所述读取指令，指示所述目标文件系统所在的操作系统通过如上所述的装置，读取并返回所述目标文件系统中已缓存的文件的缓存信息；信息获取模块，用于获取所述操作系统返回的所述缓存信息。

本申请实施例提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如上所述的信息获取方法对应的操作。

本申请实施例提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上所述的信息获取方法。

本实施例提供的方案，根据文件缓存信息读取指令，获取所述指令所指示的对象；从至少两个文件系统中，确定与所述对象对应的目标文件系统，从而可以准确地确定用于确定缓存信息的目标文件系统；再根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息，从而可以以文件系统为粒度来确定文件系统中已缓存的文件对应的缓存信息，避免了现有技术中无法确定具体缓存的文件的问题；并且，由于文件系统中存在的软连接、硬链接、链接嵌套等均直接对应于文件系统中的一个或多个文件，因此以文件系统为粒度确定缓存信息时，可以遍历文件系统中的文件，使得软连接、硬链接等在文件系统中对应的文件包含于遍历的文件中，进而在确定缓存信息时无需对软连接、硬链接等进行处理，使得本实施例提供的方案的实现简单，效率较高。

附图说明

后文将参照附图以示例性而非限制性的方式详细描述本申请实施例的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。附图中：

图1为本申请实施例一中的信息获取方法的流程示意图；

图2a为本申请实施例二中的信息获取方法的流程示意图；

图2b为本申请实施例二中的获取缓存信息的方法流程示意图；

图3为本申请实施例三中的信息获取方法的流程示意图；

图4a为本申请实施例四中的信息获取方法的流程示意图；

图4b为本申请实施例四中的文件路径的确定方法的流程示意图；

图5a为本申请实施例五中的信息获取方法的流程示意图；

图5b为本申请实施例五中的操作系统的结构示意图；

图6为本申请实施例六中的信息获取装置的结构示意图；

图7为本申请实施例七中的信息获取装置的结构示意图；

图8为本申请执行信息获取方法的一些电子设备的硬件结构示意图。

具体实施方式

实施本申请实施例的任一技术方案必不一定需要同时达到以上的所有优点。

为了使本领域的人员更好地理解本申请实施例中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请实施例一部分实施例，而不是全部的实施例。基于本申请实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请实施例保护的范围。

下面结合本申请实施例附图进一步说明本申请实施例具体实现。

图1为本申请实施例一中的信息获取方法的流程示意图；如图1所示，其包括以下步骤：

S102、根据文件缓存信息读取指令，获取所述指令所指示的对象。

文件缓存信息读取指令可以在需要的时候以任意适当的方式生成，可以由操作系统生成，也可以由应用程序生成，或由其他需要读取缓存信息的进程生成，本实施例对此不进行限定。

文件系统是操作系统用于明确存储设备(常见的是磁盘,也有基于NAND Flash的固态硬盘)或分区上的文件的方法和数据结构。文件系统可以为任意格式的文件系统，本实施例对此不进行限定。例如，一台机器上的LINUX操作系统可同时支持诸如ext2、ext3、ext4、nfs等十多种文件系统。

对象可以用于标识文件系统。对象可以是预先生成，一般来说，一个对象可以与一个文件系统或多个文件系统对应，对象与文件系统的对应关系可以预先确定并存储。由于一个操作系统中可能存在多个文件系统，因此，用于标识文件系统的对象的数量也对应为多个，指令所指示的对象可以为用于标识文件系统的对象中的部分或全部。文件系统和标识文件系统的对象的对应关系可以由本领域的技术人员根据需求设置，只要能够通过对象标识文件系统即可，本实施例对此不进行限定。

需要说明的是，本申请实施例中，如无特殊说明，“多个”、“多种”等与“多”有关的数量均指两个及两个以上。

S104、从至少两个文件系统中，确定与所述对象对应的目标文件系统。

基于对象和文件系统的对应关系，则根据上述步骤S102获取的对象，可以直接从至少两个文件系统中，确定与获取的对象对应的目标文件系统。

S106、根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息。

每个文件系统中都可以包括一个或多个文件，已缓存的文件可以包括：部分或全部内容被缓存在物理内存中的文件。

对目标文件系统中的文件进行遍历时，可以针对目标文件系统中的每个文件，判断文件是否为已缓存的文件，从而可以根据对文件系统中的文件的遍历结果，确定目标文件系统中所有已缓存的文件。

由于已缓存的文件是直接根据目标文件系统中的文件的遍历结果确定的，生成的即为目标文件系统对应的缓存信息，即确定的缓存信息对应的粒度(基本单位)为文件系统。

文件系统中还存在软连接(Soft Link)、硬链接(Hard Link)、链接嵌套等，软连接又称符号链接,软连接在其所属的文件系统中对应有一个文件，这个文件包含了另一个文件的路径名，硬链接实际就是一个文件的一个或多个文件名。无论是软连接、硬链接，或是链接嵌套等，均对应于文件系统中的一个或多个文件，因此本申请中，通过直接通过文件遍历结果来确定目标文件系统的缓存信息，被遍历的文件中即包括软连接、硬链接等对应的文件，因此无需另外对软连接、硬链接等进行处理，使得本实施例提供的方案的实现简单，效率较高。

在具体实现时，目标文件系统中可以包括文件对应的链表，根据链表可以确定目标文件系统中所有的文件，然后可以遍历根据链表确定的文件，从而遍历目标文件系统中的文件。当然，针对不同的文件系统，确定文件的方法也可能不相同，本领域的技术人员可根据需求进行选取，本实施例对此不进行限定。

本实施例提供的方案，根据文件缓存信息读取指令，获取所述指令所指示的对象；从至少两个文件系统中，确定与所述对象对应的目标文件系统，从而可以准确地确定用于确定缓存信息的目标文件系统；再根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息，从而可以以文件系统为粒度来确定文件系统中已缓存的文件对应的缓存信息，避免了现有技术中无法确定具体缓存的文件的问题；并且，由于文件系统中存在的软连接、硬链接、链接嵌套等均直接对应于文件系统中的一个或多个文件，因此以文件系统为粒度确定缓存信息时，可以遍历文件系统中的文件，使得软连接、硬链接等在文件系统中对应的文件包含于遍历的文件中，进而在确定缓存信息时无需对软连接、硬链接等进行处理，使得本实施例提供的方案的实现简单，效率较高。

本实施例的信息获取方法可以由任意适当的具有数据处理能力的电子设备执行，包括但不限于：移动终端(如平板电脑、手机等)、PC机和服务器等。

图2a为本申请实施例二提中的信息获取方法的流程示意图；如图2a所示，其包括以下步骤：

S202、通过所述目标文件系统所在的操作系统中的伪文件系统，创建所述对象。

本实施例中，由于操作系统中可分为用户空间和内核空间，用户空间可以运行应用程序的空间，内核空间可以为运行操作系统的内核的空间。为了安全，一般会将两者隔离，从而防止由于应用程序的崩溃导致的操作系统内核崩溃。

伪文件系统用于进行所述操作系统的内核空间与用户空间的交互,伪文件系统可以以文件系统的方式为用户空间访问系统内核数据的操作提供接口。

本实施例中，通过在操作系统的伪文件系统中创建对象，使得应用程序可以根据伪文件系统中的对象生成文件缓存信息读取请求，并可以通过伪文件系统中的对象，将文件缓存信息读取请求触发的处理进程转换至内核空间，并由内核空间确定并返回读取请求所请求的缓存信息。

具体地，当操作系统为Linux系统时，伪文件系统可以为proc文件系统，可以在proc文件系统中创建pagecache子目录，然后在pagecache子目录下创建具有只读权限的文件作为对象，Linux系统中的每个文件系统可以对应一个对象，该对象可以为只读文件。当然，在创建时，可以仅针对Linux系统中与缓存页存在交互的文件系统创建对应的对象。例如针对ext2/3/4，nfs，tmpfs等与缓存页进行交互的文件系统，创建对应的只读文件，而针对cgroup，debugfs等不与缓存页存在交互的文件系统，则不创建对应的只读文件。

由于在使用时，仅会生成针对对象的读取请求，因此，与创建普通文件相比，通过将对象创建为只读文件，无需验证应用程序对只读文件的写入操作的有效性，直接将写入操作忽略即可，简化了操作系统的执行步骤。

S204、根据文件缓存信息读取指令，获取所述指令所指示的对象。

本步骤的具体实现方式参考上述实施例中的步骤S102，本实施例不再赘述。

S206、从至少两个文件系统中，确定与所述对象对应的目标文件系统。

具体地，可以预先确定创建的对象与文件系统的对应关系，在确定读取指令中携带的对象后，可以根据对应关系确定与对象对应的目标文件系统。

具体地，本实施例中，步骤S206可以包括：获取所述对象所标识的文件系统类型描述信息，根据所述文件系统类型描述信息，从至少两个文件系统中获取所述目标文件系统。

通过获取对象多标识的文件系统类型描述信息，可以直接根据文件系统类型描述信息确定目标文件系统，且文件系统类型描述信息可以直接通过调用系统接口获取，使得确定目标文件系统的过程更加简单方便。

以Linux系统为例，Linux系统中包括多个不同的文件系统，针对每个文件系统，都会以文件系统类型描述信息(struct file_system_type结构体)进行注册。所有文件系统的文件系统类型描述信息会存储在一个链表中，链表的表头可以由file_systems表示。通过获取的对象标识的文件系统类型描述信息，即可以从多个文件系统类型描述信息对应的链表中，确定对象所标识的目标文件系统对应的文件系统类型描述信息，并直接通过文件系统类型描述信息表征目标文件系统，即根据所述文件系统类型描述信息，从至少两个文件系统中获取所述目标文件系统。

S208、根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息。

可选地，如图2b所示，步骤S208中的“根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件”，可以包括：

S2081、获取所述目标文件系统的文件挂载点，根据所述文件挂载点对应的链表对文件进行遍历。

具体地，每个文件系统均对应有文件挂载点，文件挂载点可以为文件系统的目录入口。根据文件挂载点可以确定文件系统的结构体，从而根据结构体遍历文件系统中的文件。

不同操作系统中，文件系统的挂载方式可能不同，则文件挂载点确定的方式也可能存在差异。下面以Linux系统为例，对确定文件挂载点的方法进行说明。

Linux系统通过根目录维护所有的文件系统，所有的文件系统均通过文件挂载点挂载在根目录下，并基于根目录进行扩展，形成树形目录结构。则，在Linux系统中，可以根据获取的对象对应的文件系统类型描述信息，从根目录下包括的与至少两个文件系统对应的至少两个文件挂载点中，定位目标文件系统的文件挂载点。

确定文件挂载点后，可以确定文件挂载点对应的链表，链表中存储有文件系统中的文件标识。

当操作系统为Linux系统时，文件标识具体可以为文件对应的inode号，则用于存储文件标识的链表可以为s_inodes链表。链表可以存储于文件系统的超级块(superblock)中。

根据链表对文件进行遍历时，可以针对链表中的每一个文件标识，判断文件标识对应的文件中的物理内存页是否存在于缓存中，若存在，则记录文件标识以及存在于缓存中的页数，之后根据下一个文件标识进行判断，若不存在，则不记录，直接根据下一个文件标识进行判断。

例如，在Linux系统中，可以通过“inode->i_mapping->

nrpages”命令来判断文件标识对应的文件中的物理内存页是否存在于缓存中；若“inode->i_mapping->nrpages”返回的值大于0，则确定文件的物理内存页存在于缓存中，且返回的值即为存在于缓存中的物理内存页的页数。

由于操作系统中的物理内存页的大小一般是标准的，例如一个物理内存页的标准大小可以为4K，因此根据存在于缓存中的页数，可以直接确定文件占用的缓存的大小。

S2082、根据对所述文件的遍历结果，确定所述目标文件系统中已缓存的文件。

具体地，若遍历时对已缓存的文件对应的文件标识进行了记录，则可以将遍历后的记录作为遍历结果，根据记录确定的文件标识即为目标文件系统中已缓存的文件对应的文件标识。或者，在遍历过程中，每确定一个已缓存的文件，即可输出其对应的文件标识，则遍历完成后，所有被输出的文件标识即为目标文件系统中已缓存的文件对应的文件标识。

具体地，本实施例中，在确定目标文件系统中已缓存的文件后，获取的已缓存的文件的缓存信息可以包括：获取已缓存的文件对应的文件标识以及缓存页数。

文件标识和缓存页数的确定方式可以通过上述内存够确定，本实施例不再赘述。

通过文件标识，可以准确地定位目标文件系统中被缓存的文件，通过缓存页数，可以方便地统计目标文件系统中的每个已缓存的文件所占用的缓存大小，进而可以方便地基于文件标识以及缓存页数，对文件占用的缓存进行分析、优化。

可选地，本实施例中，在步骤S208之后，所述方法还可以包括：

S210、将已缓存的所述文件的缓存信息写入所述对象中。

通过将缓存信息写入对象中，其他内容可以直接读取对象来确定对象标识的文件系统的缓存信息，使得信息获取更加方便。

具体地，根据上述步骤S202中的内容可知，用于标识文件系统的对象具体可以在伪文件系统中创建，则通过将缓存信息写入对象中，使得用户空间和内核空间，均可以直接读取用于标识目标文件系统的对象中的数据来确定目标文件系统的缓存信息，无需再经过其他数据传输过程，简化了操作流程。

本实施例提供的方案，根据文件缓存信息读取指令，获取所述指令所指示的对象；从至少两个文件系统中，确定与所述对象对应的目标文件系统，从而可以准确地确定用于确定缓存信息的目标文件系统；再根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息，从而可以以文件系统为粒度来确定文件系统中已缓存的文件对应的缓存信息，避免了现有技术中无法确定具体缓存的文件的问题；并且，由于文件系统中存在的软连接、硬链接、链接嵌套等均直接对应于文件系统中的一个或多个文件，因此以文件系统为粒度确定缓存信息时，可以通过遍历文件系统中的文件，直接确定软连接、硬链接等在文件系统中对应的文件是否已缓存，无需对软连接、硬链接等进行处理，使得本实施例提供的方案的实现简单，效率较高；另外，通过在伪文件系统中创建标识文件系统的对象，并将确定的缓存信息写入对象，使得用户空间和内核空间，均可以直接读取用于标识目标文件系统的对象中的数据来确定目标文件系统的缓存信息，简化了操作流程。

另外需要说明的是，本实施例的上述步骤S204-S210均可以在内核空间执行，且具体可以通过内核驱动调用内核接口执行，无需对操作系统的内核进行任何的修改。本实施例中所有关于Linux系统的相关说明均为举例说明，并不作为本实施例的限定，本领域的技术人员可根据上述举例说明，直接确定将本实施例应用至其他操作系统的方案，这也在本申请的保护范围内。

本实施例的信息获取方法可以由任意适当的具有数据处理能力的电子设备执行，包括但不限于：移动终端(如平板电脑、手机等)、PC机和服务器等。

图3为本申请实施例三提供的信息获取方法的流程示意图；如图3所示，其包括以下步骤：

S302、根据文件缓存信息获取请求生成用于读取目标文件系统的文件缓存信息的读取指令。

文件缓存信息获取请求，可以由任意需要获取缓存信息的应用程序、操作系统或进程确定，本实施例对此不进行限定。

文件缓存信息获取请求可以为获取所有文件系统的缓存信息，则根据文件缓存信息获取请求生成的文件缓存信息的读取指令可以为多个，读取指令可以与用于指示文件系统的对象一一对应，从而通过读取指令遍历所有用于标识文件系统的对象。

S304、通过所述读取指令，指示所述目标文件系统所在的操作系统读取并返回所述目标文件系统中已缓存的文件的缓存信息。

其中，操作系统读取并返回所述目标文件系统中已缓存的文件的缓存信息的具体实现，可以通过上述实施例一或实施例二中的方法实现，本实施例不再赘述。

S306、获取所述操作系统返回的所述缓存信息。

本实施例中，若在步骤S302中生成的读取指令为多个，则针对每个读取指令，均可以执行一次本步骤S304以及下述步骤S306，从而获取多个读取指令对应的多个缓存信息，进而可以根据多个缓存信息，确定与整个缓存空间对应的缓存信息，即可以确定操作系统中所有已缓存的文件。

本实施例提供的方案，根据文件缓存信息获取请求生成用于读取目标文件系统的文件缓存信息的读取指令；通过所述读取指令，指示所述目标文件系统所在的操作系统通过上述实施例一或实施例二中的方法，读取并返回所述目标文件系统中已缓存的文件的缓存信息；从而可以以文件系统为粒度来确定文件系统中已缓存的文件对应的缓存信息，避免了现有技术中无法确定具体缓存的文件的问题。

本实施例的信息获取方法可以由任意适当的具有数据处理能力的电子设备执行，包括但不限于：移动终端(如平板电脑、手机等)、PC机和服务器等。

图4a为本申请实施例四中的信息获取方法的流程示意图；如图4a所示，其包括以下步骤：

S402、根据文件缓存信息获取请求生成用于读取目标文件系统的文件缓存信息的读取指令。

S404、通过所述读取指令，指示所述目标文件系统所在的操作系统读取并返回所述目标文件系统中已缓存的文件的缓存信息。

其中，操作系统读取并返回所述目标文件系统中已缓存的文件的缓存信息的具体实现，可以通过上述实施例一或实施例二中的方法实现，本实施例不再赘述。

S406、获取所述操作系统返回的所述缓存信息。

本实施例中的S402-S406的具体实现方式可参考上述实施例，本实施例不再赘述。

可选地，若获取的所述缓存信息包括：所述目标文件系统中已缓存的文件对应的文件标识。则在步骤S406之后，所述方法还包括：

S408、确定所述文件标识所标示的文件对应的文件路径，并向用户展示所述文件路径。

由于文件系统中的文件一般通过文件路径展示给用户，也通过文件路径被读取等，因此，通过确定文件路径并向用户展示文件路径，可以使用户根据文件路径直接确定已缓存的文件，另外，应用程序也可以根据文件路径读取文件，以进行分析。

如图4b所示，步骤S408具体包括：

S4081、根据所述目标文件系统对应的所述对象，获取所述目标文件系统的文件挂载点。

文件挂载点的具体内容可参考上述实施例二中的相关叙述，在此不再赘述。

具体地，若操作系统为Linux系统，则确定的文件标识可以为文件在目标文件系统中的inode号。目标文件系统的文件挂载点，可以通过mount命令获取。

S4082、根据所述文件标识，从获取的所述目标文件系统的文件挂载点中查找所述文件标识对应的文件名，以确定所述文件标识对应的文件路径，并向用户展示所述文件路径。

具体地，由于文件挂载点为目标文件系统的目录入口，则通过在文件挂载点中进行查找，可以直接获取文件标识对应的文件名，并可以直接根据文件名确定对应的文件路径，过程较为简单。

具体地，若操作系统为Linux系统，则可以通过find<mountpoint>-xdev-inum<inodeno>命令，从相应文件系统的文件挂载点查找到对应的文件名。当然，其他操作系统中，从可以通过其他方式从文件挂载点中查找文件标识对应的文件名，这也在本申请的保护范围内。

本实施例中，由于步骤S4081以及S4082均在获取缓存信息之后执行，因此，即使步骤S4081以及S4082中查找过程的执行可能会对缓存空间中缓存的文件产生影响，也不会影响获取的缓存信息的准确性，进而保证了缓存分析的结果的准确性。

进一步地，本实施例中，在向用户展示文件路径前，可以按照确定的缓存大小，对已缓存中的文件进行排序。然后再按照排序结果，输出每个已缓存的文件对应的文件标识、文件所在的文件系统、文件路径、文件对应的缓存大小等信息。

本实施例中，获取文件挂载点以及查找文件名的过程可以直接在用户空间执行，无需转换至内核空间。

本实施例提供的方案，根据文件缓存信息获取请求生成用于读取目标文件系统的文件缓存信息的读取指令；通过所述读取指令，指示所述目标文件系统所在的操作系统通过上述实施例一或实施例二中的方法，读取并返回所述目标文件系统中已缓存的文件的缓存信息；从而可以以文件系统为粒度来确定文件系统中已缓存的文件对应的缓存信息，避免了现有技术中无法确定具体缓存的文件的问题；并且，可以直接向用户展示已缓存的文件对应的文件路径。

本实施例的信息获取方法可以由任意适当的具有数据处理能力的电子设备执行，包括但不限于：移动终端(如平板电脑、手机等)、PC机和服务器等。

图5a为本申请实施例五中的信息获取方法的流程示意图；本实施例中，以Linux系统为例，对信息获取方法的整体流程进行示例性说明。

如图5b所示，本实施例中的下述步骤均由操作系统中包括内核驱动(位于内核空间中)和用户脚本(位于用户空间中)执行。且，本实施例中，以操作系统为Linux系统为例，并预先在Linux系统的proc文件系统(伪文件系统)下创建pagecache子目录，在pagecache子目录下为每个与缓存存在交互的文件系统创建具有只读权限的文件，具体包括只读文件1、只读文件2……只读文件n。

如图5a所示，其包括以下步骤：

S501、通过用户脚本，依次遍历/proc/pagecache/目录下的所有只读文件，生成每个只读文件对应的文件缓存信息读取指令。

用户脚本在用户空间执行，只读文件和与缓存存在交互的文件系统一一对应，只读文件用于标识对应的文件系统。

根据每个文件缓存信息读取指令，执行下述步骤S502-S510。

S502、针对每个文件缓存信息读取指令所指示的只读文件，通过内核驱动回调函数，来调用Linux提供的get_fs_type接口，获取只读文件指示的目标文件系统对应的struct file_system_type结构体。

其中，只读文件即前述实施例中的所述对象的一种具体实现形式。

S503、通过内核驱动调用Linux提供的接口iterate_supers_type获取目标文件系统中所有的文件挂载点的超级块。

文件系统的超级块(super block)相当于文件系统的地图。在超级块中保存着文件系统的属性信息和资源使用情况等信息，以及通过s_inodes链表的形式保存有文件系统中的文件对应的inode号。文件系统通过超级块来了解磁盘的布局，查找已用和可用资源等。

针对每个超级块，执行步骤S504-S508。

S504、通过内核驱动确定文件挂载点对应超级块中的s_inodes链表，并确定s_inodes链表中的第i个inode号。

S505、针对第i个inode号，通过内核驱动执行inode->i_mapping->nrpages命令。

另外，如果该inode号对应的inode->i_mapping->nrpages>0，则可以直接执行步骤S507；反之，则可以执行步骤S506后，再执行步骤S507。

S506、通过内核驱动输出第i个inode号以及其对应的inode->i_mapping->nrpages返回的缓存页数，作为缓存信息输出至与目标文件系统对应的只读文件中。

地址空间中有page存在于pagecache中，即inode->i_mapping->nrpages>0，则向用户空间输出该inode的inode号和inode->i_mapping->nrpages的值。其中inode号表示在文件系统中唯一标识一个文件，inode->i_mapping->nrpages的值表示该文件在pagecache中缓存的p页数，在Linux系统中默认页是4K大小。

本实施例中，缓存采用页缓存pagecache的形式，pagecache又称为页高速缓冲存储器，简称页高缓。每个pagecache的大小为一页，通常为4K。在linux读写文件时，pagecache用于缓存文件的逻辑内容，从而可以减少IO操作，加快对磁盘上映像和数据的访问，提高了文件读取效率。

S507、通过内核驱动判断第i个inode号是否为s_inodes链表中的最后一个inode号。

如果不是，则将i＝i+1，并返回执行步骤S505，如果是，则执行步骤S508。

S508、通过内核驱动判断当前的超级块是否为最后一个超级块。

如果不是，则确定下一个超级块，并再次执行S504，如果是，则执行步骤S509。

S509、通过用户脚本，获取只读文件中存储的目标文件系统的缓存信息，缓存信息包括文件的inode号以及缓存页数。

S510、通过用户脚本执行mount命令，获取目标文件系统的文件挂载点。

S511、通过用户脚本执行find<mountpoint>-xdev-inum<inodeno>命令，从目标文件系统的文件挂载点中查找到inode号对应的文件名。

由于find命令的执行在获取缓存信息之后，因此即使find命令执行时会对缓存产生影响，也可以保证缓存信息的准确性。

查找到所有inode号对应的文件名后，执行步骤S512。

S512、通过用户脚本将所有inode号按照其对应的缓存页数的大小，以从大到小的顺序排列。

S513、通过用户脚本按照排序结果输出每个文件对应的inode号、文件所在的文件系统、文件路径，文件对应的缓存大小(或者缓存页数)。

本实施例提供的方案，在遍历文件系统中的文件时，直接根据inode号遍历整个文件系统中的文件，无需处理文件系统中的软连接、硬链接等，实现简单，效率较高；并且，上述方案直接通过内核驱动和用户脚本执行，因此实现时无需修改操作系统，且所有的步骤均可以通过Linux系统的接口实现，分析过程的执行更加方便；遍历过程仅针对于缓存(pagecache)存在交互的文件系统，而并非所有的文件系统，使得遍历过程更加高效，并可以准确地确定所有与缓存存在交互的文件系统对应的缓存信息，从而能够准确地分析Linux系统中的共享内存对缓存的开销贡献，更方便进行优化。

图6为本申请实施例六中的信息获取装置的结构示意图；如图6所示，其包括：对象获取模块602、系统确定模块604、缓存信息确定模块606。

对象获取模块602，用于根据文件缓存信息读取指令，获取所述指令所指示的对象。

系统确定模块604，用于从至少两个文件系统中，确定与所述对象对应的目标文件系统。

缓存信息确定模块606，用于根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息。

可选地，本申请任一实施例中，所述缓存信息确定模块606包括：文件挂载点获取模块，用于获取所述目标文件系统的文件挂载点，根据所述文件挂载点对应的链表对文件进行遍历，其中，所述链表中存储有文件系统中的文件标识；缓存文件确定模块，用于根据对所述文件的遍历结果，确定所述目标文件系统中已缓存的文件。

可选地，本申请任一实施例中，所述缓存信息确定模块606包括：获取模块，用于获取已缓存的文件对应的文件标识以及缓存页数。

可选地，本申请任一实施例中，所述系统确定模块604包括：描述信息获取模块，用于获取所述对象所标识的文件系统类型描述信息，根据所述文件系统类型描述信息，从至少两个文件系统中获取所述目标文件系统。

可选地，本申请任一实施例中，所述装置还包括：写入模块，用于将已缓存的所述文件的缓存信息写入所述对象中。

可选地，本申请任一实施例中，所述装置还包括：对象创建模块，用于通过所述目标文件系统所在的操作系统中的伪文件系统，创建所述对象，其中，所述伪文件系统用于进行所述操作系统的内核空间与用户空间的交互。

本实施例提供的方案，根据文件缓存信息读取指令，获取所述指令所指示的对象；从至少两个文件系统中，确定与所述对象对应的目标文件系统，从而可以准确地确定用于确定缓存信息的目标文件系统；再根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息，从而可以以文件系统为粒度来确定文件系统中已缓存的文件对应的缓存信息，避免了现有技术中无法确定具体缓存的文件的问题；并且，由于文件系统中存在的软连接、硬链接、链接嵌套等均直接对应于文件系统中的一个或多个文件，因此以文件系统为粒度确定缓存信息时，可以遍历文件系统中的文件，使得软连接、硬链接等在文件系统中对应的文件包含于遍历的文件中，进而在确定缓存信息时无需对软连接、硬链接等进行处理，使得本实施例提供的方案的实现简单，效率较高。

图7为本申请实施例七中的信息获取装置的结构示意图；如图7所示，其包括：指令生成模块702、信息返回模块704、信息获取模块706。

指令生成模块702，用于根据文件缓存信息获取请求生成用于读取目标文件系统的文件缓存信息的读取指令。

信息返回模块704，用于通过所述读取指令，指示所述目标文件系统所在的操作系统通过如实施例六中的装置，读取并返回所述目标文件系统中已缓存的文件的缓存信息。

信息获取模块706，用于获取所述操作系统返回的所述缓存信息。

可选地，本申请任一实施例中，获取的所述缓存信息包括：所述目标文件系统中已缓存的文件对应的文件标识；对应的，所述装置还包括：路径确定模块，用于确定所述文件标识所标示的文件对应的文件路径，并向用户展示所述文件路径。

可选地，本申请任一实施例中，所述路径确定模块，包括：挂载确定模块，用于根据所述目标文件系统对应的所述对象，获取所述目标文件系统的文件挂载点；查找模块，用于根据所述文件标识，从获取的所述目标文件系统的文件挂载点中查找所述文件标识对应的文件名，以确定所述文件标识对应的文件路径，并向用户展示所述文件路径。

本实施例提供的方案，根据文件缓存信息读取指令，获取所述指令所指示的对象；从至少两个文件系统中，确定与所述对象对应的目标文件系统，从而可以准确地确定用于确定缓存信息的目标文件系统；再根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息，从而可以以文件系统为粒度来确定文件系统中已缓存的文件对应的缓存信息，避免了现有技术中无法确定具体缓存的文件的问题；并且，由于文件系统中存在的软连接、硬链接、链接嵌套等均直接对应于文件系统中的一个或多个文件，因此以文件系统为粒度确定缓存信息时，可以遍历文件系统中的文件，使得软连接、硬链接等在文件系统中对应的文件包含于遍历的文件中，进而在确定缓存信息时无需对软连接、硬链接等进行处理，使得本实施例提供的方案的实现简单，效率较高。

图8为本申请执行信息获取方法的一些电子设备的硬件结构示意图。根据图8所示，该设备包括：

一个或多个处理器802以及存储器804，图8中以一个处理器802为例。

执行信息获取方法的设备还可以包括：通信接口(Communications Interface)806以及通信总线808。

通信接口806，用于与其它电子设备或服务器进行通信。

处理器802、存储器804、通信接口806可以通过通信总线808完成相互间的通信。

存储器804作为一种非易失性计算机可读存储介质，可用于存储至少一可执行指令,可执行指令具体可以包括程序810，程序810具体可以包括非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施例中的信息获取方法对应的程序指令/模块。处理器802通过运行存储在存储器804中的程序810，实现上述方法实施例中信息获取方法。

存储器804可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据信息获取装置的使用所创建的数据等。此外，存储器804可以包括高速随机存取存储器804，还可以包括非易失性存储器804，例如至少一个磁盘存储器804件、闪存器件、或其他非易失性固态存储器804件。在一些实施例中，存储器804可选包括相对于处理器802远程设置的存储器804，这些远程存储器804可以通过网络连接至信息获取装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述一个或者多个模块存储在所述存储器804中，当被所述一个或者多个处理器802执行时，执行上述任意方法实施例中的信息获取方法。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

本申请实施例的电子设备以多种形式存在，包括但不限于:

(1)移动通信设备:这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括:智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备:这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括:PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备:这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器:提供计算服务的设备，服务器的构成包括处理器802、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

至此，已经对本主题的特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作可以按照不同的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序，以实现期望的结果。在某些实施方式中，多任务处理和并行处理可以是有利的。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (13)

1.一种信息获取方法，包括：

根据文件缓存信息读取指令，获取所述指令所指示的对象；

从至少两个文件系统中，确定与所述对象对应的目标文件系统；

根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息。

2.根据权利要求1所述的方法，其中，所述根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，包括：

获取所述目标文件系统的文件挂载点，根据所述文件挂载点对应的链表对文件进行遍历，其中，所述链表中存储有文件系统中的文件标识；

根据对所述文件的遍历结果，确定所述目标文件系统中已缓存的文件。

3.根据权利要求2所述的方法，其中，所述获取已缓存的所述文件的缓存信息，包括：

获取已缓存的文件对应的文件标识以及缓存页数。

4.根据权利要求1所述的方法，其中，所述从至少两个文件系统中，确定与所述对象对应的目标文件系统包括：

获取所述对象所标识的文件系统类型描述信息，根据所述文件系统类型描述信息，从至少两个文件系统中获取所述目标文件系统。

5.根据权利要求1所述的方法，其中，所述方法还包括：将已缓存的所述文件的缓存信息写入所述对象中。

6.根据权利要求1所述的方法，其中，在所述根据文件缓存信息读取指令，获取所述指令所指示的对象之前，所述方法还包括：

通过所述目标文件系统所在的操作系统中的伪文件系统，创建所述对象，其中，所述伪文件系统用于进行所述操作系统的内核空间与用户空间的交互。

7.一种信息获取方法，包括：

根据文件缓存信息获取请求生成用于读取目标文件系统的文件缓存信息的读取指令；

通过所述读取指令，指示所述目标文件系统所在的操作系统通过如权利要求1-6任一项所述的方法，读取并返回所述目标文件系统中已缓存的文件的缓存信息；

获取所述操作系统返回的所述缓存信息。

8.根据权利要求7所述的方法，其中，获取的所述缓存信息包括：所述目标文件系统中已缓存的文件对应的文件标识；

对应的，所述方法还包括：确定所述文件标识所标示的文件对应的文件路径，并向用户展示所述文件路径。

9.根据权利要求8所述的方法，其中，所述确定所述文件标识所标示的文件对应的文件路径，并向用户展示所述文件路径，包括：

根据所述目标文件系统对应的所述对象，获取所述目标文件系统的文件挂载点；

根据所述文件标识，从获取的所述目标文件系统的文件挂载点中查找所述文件标识对应的文件名，以确定所述文件标识对应的文件路径，并向用户展示所述文件路径。

10.一种信息获取装置，包括：

对象获取模块，用于根据文件缓存信息读取指令，获取所述指令所指示的对象；

系统确定模块，用于从至少两个文件系统中，确定与所述对象对应的目标文件系统；

缓存信息确定模块，用于根据对所述目标文件系统中的文件的遍历结果，确定所述目标文件系统中已缓存的文件，并获取已缓存的所述文件的缓存信息。

11.一种信息获取装置，包括：

指令生成模块，用于根据文件缓存信息获取请求生成用于读取目标文件系统的文件缓存信息的读取指令；

信息返回模块，用于通过所述读取指令，指示所述目标文件系统所在的操作系统通过如权利要求10所述的装置，读取并返回所述目标文件系统中已缓存的文件的缓存信息；

信息获取模块，用于获取所述操作系统返回的所述缓存信息。

12.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-6或7-9任一项所述的信息获取方法对应的操作。

13.一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1-6或7-9中任一项所述的信息获取方法。

Images