更新反向映射元数据的方法及装置与流程

本发明涉及数据存储技术领域，特别涉及一种更新反向映射元数据的方法及装置。

背景技术：

在大数据的背景下，数据存储技术发展迅速。如今，为实现节省存储空间的目的，一个数据块在服务器中存储一次即可，如果某些应用需使用该数据块，则不必重复存储，而是为这些应用分配VLUN(Virtual LUN(Logical Unit Number，逻辑单元号)，虚拟逻辑单元号)，且VLUN的VLBA(Virtual LUN(Logical Unit Number，逻辑单元号)Logic Block Address，虚拟逻辑区块地址)上存储该数据块所在的PLBA(Physical LUN(Logical Unit Number，逻辑单元号)Logic Block Address，物理逻辑区块地址)，使得VLBA可以引用数据块。当然，如果数据块不再被引用，则需回收数据块所在的存储空间。因此，每次数据块被引用时，则添加一个PLBA到VLBA的反向映射元数据，以标志该数据块处于被引用状态。一旦检测到不存在反向映射元数据对应该PLBA，则对PLBA所在的存储区域进行回收。当然，随着应用对数据块需求的变化，反向映射元数据可能会更新。

例如，对于服务器中已存储的数据块A，当建立或取消VLBA到PLBA的引用关系时，生成反向映射元数据的更新请求，进而，服务器在系统日志中记录该更新请求，再基于更新请求的标识，在缓存中更新反向映射元数据。如果该标识指示添加反向映射元数据，则将更新请求存储至缓存中，如果该标识指示删除反向映射元数据，则将缓存中具有相同反向映射元数据的更新请求删除。需要说明的是，对应同一个PLBA的更新请求在缓存中有序存储。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

由于对应同一个PLBA的更新请求在缓存中有序存储，则每次更新反向映射元数据时，如，在缓存中插入新的更新请求或者删除旧的更新请求，缓存中更新请求的存储位置均会重新调整，造成一定的时延，导致更新效率低。由于反向映射元数据的数据量大，则在缓存中存储反向映射元数据会占用大量内存。

技术实现要素：

为了解决现有技术的问题，本发明实施例提供了一种更新反向映射元数据的方法及装置。所述技术方案如下：

第一方面，提供了一种更新反向映射元数据的方法，所述方法包括：

接收更新请求，所述更新请求用于指示添加或删除反向映射元数据；将所述更新请求存储至系统日志；根据回收进程的工作状态，判断是否在所述缓存中更新所述反向映射元数据；如果确定不在所述缓存中更新所述反向映射元数据，则直到回收进程启动之前，或所述系统日志已满时，将所述系统日志中所存储的更新请求合并至指定存储区域中的反向映射元数据。

其中，系统日志用于服务器存储更新请求，在存储时，以保护反向映射元数据的完整性、安全性为目的，不会对更新请求做进一步处理。

回收进程是指服务器回收存储区域的进程，一般地，服务器可以在回收进程中删除没有反向映射元数据对应的存储区域上的数据块，从而回收该存储区域。

回收进程的工作状态是指回收进程是否启动，或者回收进程启动之后所达到的阶段。

指定存储区域是指与服务器连接的存储区域，可用于存储反向映射元数据即可，本发明对指定存储区域不做具体限定。例如，指定存储区域可以是SAN(Storage Area Network，存储区域网络)、磁盘或NAS(Network Attached Storage，网络附加存储)。一般地，指定存储区域的存储空间较大，还可以用于存储服务器所需的各种数据，如，本发明实施例涉及的数据块及反向映射元数据。

本发明实施例中，服务器根据回收进程的工作状态，判断是否在所述缓存中更新所述反向映射元数据，从而提供了不在缓存中更新反向映射元数据的方案，在回收进程启动之前，从系统日志中已存储的更新请求提取出反向映射元数据，且合并至指定存储区域上，以保证反向映射元数据的完整性。由于反向映射元数据更新频繁，但是基本仅在回收进程中使用，因此，本发明实施例对于多数更新反向映射元数据的过程可以减少时延，提高更新效率，且占用较少内存。

在第一方面的第一种可能实现方式中，所述根据回收进程的工作状态，判断是否在所述缓存中更新所述反向映射元数据包括：

检测是否启动所述回收进程；

如果启动所述回收进程，则判断所述更新请求对应的第一存储区域是否处于所述回收进程；

如果所述第一存储区域处于所述回收进程，则判断所述缓存是否已满；

如果所述缓存未满，则确定在所述缓存中更新所述反向映射元数据；或，

如果所述缓存已满，则确定在所述缓存中更新所述反向映射元数据，并删除所述缓存中对应于同一个第二存储区域且占用缓存空间最大的更新请求，且将第二存储区域从所述回收列表中移除。

在第一种可能实现方式中，在第一存储区域处于回收进程时，服务器允许在缓存中更新反向映射元数据，使得回收进程中服务器可以从缓存中读取到最新的更新请求，并基于最新的更新请求进行回收，提高了回收准确性。而且，在缓存已满的情况下，提供了释放缓存空间的方式，从而留出缓存的存储资源，提高缓存的利用率。

在第一方面的第二种可能实现方式中，所述根据回收进程的工作状态，判断是否在所述缓存中更新所述反向映射元数据包括：

如果未启动所述回收进程，则确定不在所述缓存中更新所述反向映射元数据；或，

如果所述第一存储区域未处于所述回收进程，则确定不在所述缓存中更新所述反向映射元数据；或，

如果所述缓存已满，则确定不在所述缓存中更新所述反向映射元数据，并删除所述缓存中对应所述第一存储区域的更新请求，且将第一存储区域从回收列表中移除，所述回收列表用于指示本次回收进程中所要回收的存储区域。

在第二种可能实现方式中，提供了多种用于判断是否需要在缓存中更新该反向映射元数据的方式，基于回收进程是否启动或第一存储区域是否处于回收进程等具体的运行状态，来确定后续的具体实现方式，服务器未启动回收进程，或者第一存储区域未处于回收进程，或者缓存已满时，由于反向映射元数据已在系统日志中存储过，不必在缓存中更新反向映射元数据，解决了相关技术占用大量内存、时延高、更新效率低问题。另外，该方式在缓存已满时提供了释放缓存空间的策略，从而留出更多的存储资源，以提高缓存的利用率，进一步提高服务器的读写效率。

在第一方面的第三种可能实现方式中，所述如果所述缓存未满，则确定在所述缓存中更新所述更新请求之后，所述方法还包括：

判断所述回收进程的进度；

如果所述回收进程已完成从所述缓存及所述指定存储区域中读取对应所述第一存储区域的反向映射元数据的过程，且所述更新请求指示添加反向映射元数据，则为所述第一存储区域添加指定标记，所述指定标记用于指示在本次回收进程中不回收被标记的存储区域。

在第三种可能实现方式中，如果回收进程已完成从缓存及指定存储区域中读取对应第一存储区域的反向映射元数据的过程，说明当前所更新的反向映射元数据没有在回收进程中被读取，此时，为了避免第一存储区域被误删，服务器为第一存储区域添加指定标记，从而提高回收的准确性。

在第一方面的第四种可能实现方式中，所述方法还包括：

当启动所述回收进程时，基于所述缓存及所述指定存储区域中的反向映射元数据执行所述回收进程，所述回收进程用于回收不具有指定标记且不具有反向映射元数据的存储区域；

当本次回收进程结束时，删除所述指定标记及所述缓存中所有的反向映射元数据；

其中，所述本次回收进程完成对任一存储区域的回收时，删除所述缓存中对应所述任一存储区域的反向映射元数据。

在第四种可能实现方式中，更新反向映射元数据时，如果回收进程也在进行，则服务器在检测到所要回收的存储区域具有指定标记时，不对该存储区域进行回收，以保证当前所更新的反向映射元数据、或者所删除的反向映射元数据中的VLBA可以引用该存储区域上的数据块。而且，在回收进程结束时，服务器可以删除指定标记，使得该存储区域在之后的回收进程中可以被回收。另外，该方式提供了两种释放缓存空间的策略，从而留出更多的存储资源，以提高缓存的利用率，进一步提高服务器的读写效率。

第二方面，提供了一种服务器，该服务器包括：处理器、网络接口、存储器以及总线，存储器与网络接口分别通过总线与处理器相连；处理器被配置为执行存储器中存储的指令；处理器通过执行指令来实现上述第一方面或第一方面中任意一种可能的实现方式所提供的更新反向映射元数据的方法。

第三方面，提供了一种服务器，该服务器包括至少一个模块，该至少一个模块用于实现上述第一方面或第一方面中任意一种可能的实现方式所提供的更新反向映射元数据的方法。

上述第二方面和第三方面所获得的技术效果与第一方面对应的技术手段获得的技术效果近似，在这里不再赘述。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种服务器集群系统的组成图；

图2是本发明实施例提供的一种服务器的结构示意图；

图3是本发明实施例提供的一种更新反向映射元数据的方法流程图；

图4是本发明实施例提供的一种回收方法流程图；

图5是本发明实施例提供的一种更新反向映射元数据的装置结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

图1是本发明实施例提供的一种服务器集群系统的组成图。如图1所示，该服务器集群系统通过网络层与应用客户端或者存储管理中心通信，所述服务器集群系统由服务器和网络存储节点(本实施例以SAN存储设备为例)组成，服务器和网络存储节点均可以是一个或多个，本实施例以2台SAN存储节点为例，每台服务器的物理设备包含CPU、内存、网络和硬盘等，网络存储节点的物理设备包含存储阵列和存储阵列的控制器，本实施例将服务器的CPU和内存等用于为接入所述服务器集群系统的应用程序提供计算资源的物理设备统称为所述服务器集群系统的计算资源，其为组成计算层的基础，将存储资源层的服务器的硬盘和网络存储节点的存储阵列统称为所述服务器集群系统的存储资源。

所述服务器集群用于对外将计算资源提供给不同的应用程序使用，例如可以在所述服务器集群上运行WEB应用或者HADOOP分布式集群系统。所述服务器集群的计算资源还可以进一步被抽象成多台虚拟机，在每台虚拟机上运行不同的应用程序，或者多台虚拟机组成虚拟机集群从而为同一个应用程序提供服务，本实施例对具体实现形式不拘一格。当所述服务器集群上运行应用程序，所述应用程序的相关数据可以存储在所述服务器集群系统的存储资源上，即存储在服务器的硬盘上或者SAN节点的存储阵列中，也可以同时存储在服务器的硬盘和SAN节点的存储阵列中。

所述服务器集群系统还运行了分布式存储控制器，所述分布式存储控制器用于将服务器的硬盘和网络存储节点(如SAN)提供的存储阵列的存储资源划分为多个存储分区，所述多个存储分区组成所述服务器集群系统的共享存储资源池，运行在所述服务器集群上的应用程序可以从所述共享存储资源池中获得分布的存储资源块并进行使用，保证了存储资源的较高的利用率和存储的均匀分布，并由此提升了存储资源的读写效率。在本发明实施例中所述分布式存储控制器通过安装在服务器的硬件设备上的软件模块来实现，从而可以避免另外购置硬件设备作为存储控制设备的问题，解决方案更加经济并节约成本。

本发明实施例所述分布式存储控制器是对每台服务器上运行的存储控制功能模块的统称，作为解决方案提供的分布式存储控制器可以包含不同的功能模块，而在实际部署的时候，每台服务器根据其功能和部署策略可以运行分布式存储控制器的不同的功能模块，也就是说，根据服务器集群的部署策略，可以在不同的服务器上运行分布式存储控制器的不同的功能模块，每台服务器可以运行分布式存储控制器所有的功能模块，也可以运行分布式存储控制器部分的功能模块。分布式存储控制器主要用于：对所述服务器集群系统的计算资源提供数据访问的接口，以及对所述服务器集群系统的共享存储资源进行管理和读写控制。

需要说明的是，本发明实施例提供的服务器可以为存储系统中任一个用于进行数据管理的服务器。图2是本发明实施例提供的一种服务器的结构示意图，该服务器20包括：处理器22和网络接口24。

处理器22包括一个或者一个以上处理核心。处理器22通过运行软件程序以及模块，从而执行下述更新反向映射元数据的方法所涉及的各种功能应用以及数据处理。

网络接口24可以为多个，该网络接口24用于与其它通信设备、业务终端或者网络设备进行通信。

在一种可能的实现方式中，服务器20还包括存储器26、总线28等部件。其中，存储器26与网络接口24分别通过总线28与处理器22相连。

存储器26可用于存储软件程序以及模块。具体的，存储器26可存储操作系统262、至少一个功能所需的应用程序模块264。操作系统262可以是实时操作系统(Real Time Operating System，RTOS)、LINUX、UNIX、WINDOWS或OS X之类的操作系统。

图3是本发明实施例提供的一种更新反向映射元数据的方法流程图。参见图3，该实施例应用于服务器，并以SAN(Storage Area Network，存储域网络)作为指定存储区域为例进行说明，事实上，指定存储区域也可以是磁盘或NAS(Network Attached Storage，网络附加存储)。该实施例具体步骤包括：

301、服务器接收更新请求，更新请求用于指示添加或删除反向映射元数据。

在该步骤中，更新请求携带反向映射元数据，且具有添加标识或者删除标识，添加标识用于指示添加该反向映射元数据，删除标识则用于指示删除该反向映射元数据。其中，反向映射元数据用于描述一个数据块所在的PLBA(Physical LUN Logic Block Address，物理逻辑区块地址)到VLBA(Virtual LUN Logic Block Address，虚拟逻辑区块地址)映射关系，显然，反向映射元数据包括PLBA及VLBA。

由于应用中对数据块的需求可能随时改变，一旦建立VLBA到PLBA引用的关系，或者取消VLBA到PLBA的引用关系，说明PLBA所存储的数据块不再被VLBA对应的应用使用，此时，生成更新请求，并触发反向映射元数据的更新进程。需要说明的是，更新反向映射元数据的意义在于：如果某个数据块被引用，则存在反向映射元数据对应该数据块所在的PLBA，使得回收进程中不会删除该数据块，而是将数据块复制到不被回收的存储区域，再对原来PLBA所在的存储区域进行回收；如果某个数据块不再被引用，则不存在反向映射元数据对应该数据块所在的PLBA，使得回收进程中可以删除该数据块，回收PLBA所在的存储区域。

302、服务器将更新请求存储至系统日志。

一旦接收到更新请求，则服务器在系统日志进行存储。需要说明的是，系统日志以保护反向映射元数据的完整性、安全性为目的，无论更新请求指示添加或删除反向映射元数据，系统日志均不对更新请求进行进一步处理。

303、服务器检测是否启动回收进程，如果是，执行步骤304，如果否，执行步骤306。

回收进程是指回收存储区域的进程，用于删除服务器中没有被引用的数据块，并回收这些数据块占用的存储资源。本发明实施例对回收进程的触发方式不做限定。

例如，周期性自动启动回收进程。可以在服务器中存储回收周期，并设置每次所要回收的存储区域，使得服务器自动完成回收进程。例如，对逻辑单元号为LUN1所对应的存储区域进行回收，假设LUN1对应的存储区域的大小为2TB，划分了2¹⁰个大小均为2GB的存储区域，设置回收周期为3天，则分4次回收这些存储区域，每次回收2⁸个存储区域，12天可全范围回收LUN1对应的存储区域。需要说明的是，LUN对应的是人为从SAN(Storage Area Network，存储域网络)上划分的一块存储区域，可用于存储服务器中常用的数据块。

另外，本发明实施例对回收进程采用的回收时机不做限定。例如，对于上述举例的触发方式，可以在服务器中存储回收列表，列表中的每个数据项至少包括所要回收的存储区域的地址范围。每次回收进程启动时，服务器基于回收列表中存储区域的地址范围，确定所要回收的存储区域。

发明人认识到，相关技术的回收进程中，服务器锁定一个存储区域，对该存储区域进行回收，但回收过程中，不允许更新反向映射元数据，当该存储区域回收完毕时，才解锁该存储区域，再进行下一个存储区域的回收，导致回收进程中服务器的并发处理能力差，也降低了反向映射元数据的更新效率。

为克服相关技术的问题，本发明实施例中服务器支持更新进程与回收进程并发进行。但是，考虑到回收进程的工作状态与更新过程会相互影响，因此，在本步骤中，服务器检测回收进程是否已经启动，以判断后续的更新如何进行。本发明实施例对检测的方式不做限定。例如，服务器查询回收进程的标志位，如果该标志位为1，则确定当前启动了回收进程；如果该标志位为0，则确定当前未启动回收进程。

304、如果启动回收进程，则服务器判断更新请求对应的第一存储区域是否处于回收进程，如果是，执行步骤305，如果否，执行步骤306。

第一存储区域是指更新请求携带的PLBA所在的一块存储区域。本发明实施例对第一存储区域不做进一步限定。例如，LUN2对应的存储区域上存储服务器常用的数据块，LUN2对应的存储区域的大小为2TB，第一存储区域所占据的大小为1GB，地址范围可以为LUN2的0～2³³-1比特。

本发明实施例涉及的缓存用于存储更新请求。需要说明的是，对应同一个PLBA的更新请求在缓存中有序存储，如果添加或删除更新请求，则缓存中更新请求的存储位置均会调整。本发明实施例对该存储形式不做具体限定。例如，在缓存中以数组的形式存储更新请求，对应相同PLBA的更新请求归为同一个数组。

当然，本发明实施例对判断第一存储区域是否处于回收进程的方式不做限定。例如，如果回收进程是基于回收列表进行回收，则服务器查询该第一存储区域是否属于该回收列表，如果查询到第一存储区域的地址范围在回收列表所要回收的存储区域的地址范围内，则确定第一存储区域处于回收进程，进一步地，可以执行步骤305。

305、如果第一存储区域处于回收进程，则服务器判断缓存是否已满，如果否，则服务器确定在缓存中更新反向映射元数据；如果是，则服务器确定在缓存中更新反向映射元数据，并删除缓存中对应于同一个第二存储区域且占用缓存空间最大的更新请求，且将第二存储区域从回收列表中移除，或，服务器确定不在缓存中更新反向映射元数据，并删除缓存中对应第一存储区域的更新请求，且将第一存储区域从回收列表中移除，回收列表用于指示本次回收进程中所要回收的存储区域。

如果更新请求对应的第一存储区域是否处于回收进程，则服务器判断缓存是否已满，若查询到可用的存储位置，即缓存未满时，直接在缓存中进行更新即可；若未查询到可用的存储位置，即缓存已满时，可以以至少两种方式释放缓存空间。

需要说明的是，SAN是服务器所连接的存储区域。本发明实施例是在回收进程启动之前将系统日志中的反向映射元数据进合并至SAN。在本步骤中，如果检测到当前启动了回收进程，说明在回收进程与反向映射元数据的更新过程并发进行，进而表明该更新请求没有被合并至SAN。为了提高回收的准确性，使得回程进程可以从缓存中读取到最新的更新请求，则在上述缓存未满的情况下，服务器在缓存中更新反向映射元数据。

考虑到更新请求可能是指示添加反向元数据，也可能是删除反向映射元数据，因此，本发明实施例对以上两种在缓存中更新反向映射元数据的情况分别进行说明。

第一种情况、更新请求指示添加反向映射元数据。

此时，发明人认识到，添加的反向映射元数据没有被合并至SAN，从而不能在回收进程中被读取，如果除了该新添加的反向映射元数据，回收进程所读取的反向映射元数据中，已经没有任何反向映射元数据对应该第一存储区域，则回收进程对第一存储区域进行回收，会导致添加的反向映射元数据中的VLBA不能引用该第一存储区域原有的数据块。

因此，为了避免以上情况，从而提高回收的准确性，本发明实施例将更新请求添加到缓存中对应该PLBA的存储位置，完成缓存中反向映射元数据的更新。对于回收进程来说，服务器可以在回收进程启动后，从缓存中读取到更新请求携带的反向映射元数据，从而不会删除第一存储区域中的数据块，使得数据块仍然可以被引用。

第二种情况、更新请求指示删除反向映射元数据。

此时，发明人认识到，所要删除的反向映射元数据在回收进程启动前已由系统日志合并至SAN中，从而会在回收进程中被读取，如果除了所要删除的反向映射元数据对应该第一存储区域，回收进程所读取的反向映射元数据中，没有任何反向映射元数据对应第一存储区域，则回收进程不会对第一存储区域进行回收。然而，由于该反向映射元数据应被删除，说明反向映射元数据中VLBA已经不再引用第一存储区域的数据块。

因此，为了避免以上情况，从而提高回收效率，在第二种情况中，服务器基于更新请求携带的PLBA及VLBA，在缓存中对应该PLBA的存储位置查找是否存在携带该VLBA的更新请求，如果是，则在缓存中删除原有的更新请求，使得本次回收进程可以对更新请求对应的存储区域进行回收；如果否，说明原有的反向映射元数据已合并至SAN上，则在缓存中添加该更新请求，使得在回收进程进行到合并SAN及缓存中的反向映射元数据时，可以将原有的反向映射元数据删除，从而在本次回收进程可以对更新请求对应的存储区域进行回收。

对于回收进程来说，服务器可以在回收进程启动后，从缓存中读取到指示删除该反向映射元数据的更新请求，进而将第一存储区域中的数据块删除；或者，服务器从缓存及SAN上均不会读取到添加该反向映射元数据的更新请求，使得不具有任何反向映射元数据的数据块可以被删除。

为了充分释放缓存空间，留出更多的存储资源，以提高缓存的利用率，在缓存已满时，本发明实施例至少提供以下两种释放缓存空间的策略：

305A、如果缓存已满，则服务器确定不在缓存中更新反向映射元数据，并删除缓存中对应第一存储区域的更新请求，且将第一存储区域从回收列表中移除，回收列表用于指示本次回收进程中所要回收的存储区域。

在缓存已满的情况下，为了释放缓存空间，服务器删除对应于第一存储区域原有的更新请求。当然，为了避免删除这些更新请求后，在回收进程中误删第一存储区域的数据块，则将第一存储区域从回收列表中移除，使得本次回收进程不会回收第一存储区域，也不会删除第一存储区域上的数据块。

需要说明的是，如果服务器执行该步骤305A，则后续也可以执行步骤306。另外，这种释放缓存空间的方式不必在缓存中更新反向映射元数据，则该方式与本实施例的其他步骤结合后，也可以解决现有技术在缓存中更新所带来的时延问题及占用内存多的问题。

305B、如果缓存已满，则服务器确定在缓存中更新反向映射元数据，并删除缓存中对应于同一个第二存储区域且占用缓存空间最大的更新请求，且将第二存储区域从回收列表中移除。

为了一次性释放更多的缓存空间，并且能留出存储资源以更新反向映射元数据，服务器计算缓存中对应同一个PLBA的更新请求所占用的存储空间，如果确定某些更新请求所占用的存储空间最大，则删除这些对应于同一个PLBA的更新请求，从而腾出缓存空间。当然，为了避免删除这些更新请求后，在回收进程中误删第二存储区域的数据块，则为将第二存储区域从回收列表中移除，使得本次回收进程不会回收第二存储区域，也不会删除第二存储区域上的数据块。在该步骤305B中，服务在缓存中更新反向映射元数据的情况可参考本步骤305已说明的两种情况，此处不再赘述。

在该步骤中，如果第一存储区域处于回收进程，则确定在缓存中对更新请求进行更新之后，如果回收进程已完成从缓存及SAN中读取对应第一存储区域的反向映射元数据的过程，说明该更新请求仍然没有在回收进程中被读取，如果更新请求指示添加反向映射元数据，则为了避免回收进程将第一存储区域的数据块删除，导致反向映射元数据中的VLBA不能引用该数据块，提出以下解决方案：服务器判断回收进程的进度；如果回收进程已完成从所述缓存及所述SAN中读取对应所述第一存储区域的反向映射元数据的过程，且更新请求指示添加反向映射元数据，则为第一存储区域添加指定标记。

306、如果未启动回收进程，或如果第一存储区域未处于回收进程，则服务器确定不在缓存中更新反向映射元数据。

发明人认识到，相关技术中，每次反向映射元数据的更新过程均会在缓存中进行，而缓存中更新请求的存储位置会重新调整，造成一定的时延，导致更新效率低，由于反向映射元数据的数据量大，则在缓存中存储反向映射元数据会占用大量内存。

为解决上述问题，本发明实施例提供不在缓存中更新反向映射元数据的解决方案，即如果回收进程未启动，或者，此时的更新请求对应的存储区域未处于回收进程，则服务器不必在缓存中更新反向映射元数据。当然，这并不会影响随后的回收进程，因为反向映射元数已经在步骤302中在系统日志中进行了全面的记录，使得在回收进程启动之前，读取出系统日志中的反向映射元数据即可。

307、如果确定不在缓存中更新反向映射元数据，则服务器直到回收进程启动之前，或系统日志已满时，将系统日志中所存储的更新请求合并至存储区域网络SAN中的反向映射元数据。

本发明实施中，鉴于反向映射元数据平时仅需进行更新，基本仅在回收进程中需要读取，提供了不在缓存中更新反向映射元数据的方案。事实上，虽然系统日志的存储空间很大，但总是会满，则当系统日志已满时，将其所存储的反向映射元数据合并至存储空间更大的SAN上长期、有序地存储，以便于回收进程进行读取；或者，为了使得回收进程启动时，能读取到系统日志所存储的、还未合并至SAN上反向映射元数据，在回收进程启动之前，整理系统日志所存储的更新请求，从中提取反向映射元数据，再合并至SAN上。此时，系统日志中原有的反向映射元数据已备份至SAN上，则系统日志可以被清空，以释放存储空间。

另外，上述合并过程发生在回收进程启动之前，也即是，在回收进程将启动时，服务器先进行该合并过程。本发明实施对实现这种时序的方式不做限定。例如，在服务器中进行设置时序，当触发回收进程时，首先进行该合并过程，再启动回收进程。

需要说明的是，本步骤以不在缓存中更新反向映射元数据的情况为例，说明了后续反向映射元数据在SAN中进行更新的过程。事实上，无论反向映射元数据是否在缓存中进行更新，一旦系统日志已满或者回收进程启动之前，均要将系统日志中的反向映射元数据合并至SAN，以确保系统日志能够继续存储新的更新请求，且服务器在回收进程中可以确定所要回收的存储区域。

另外，还要说明的是，本发明实施例是以反向映射元数据的更新过程为例进行说明，事实上，如果存在一类数据也具有反向映射元数据的两个特点，1、更新频繁；2、使用频率较低。即写入频繁，但很少被读取的数据也可以运用本发明实施例所示的方案进行更新。

相关技术中，由于对应同一个PLBA的更新请求在缓存中有序存储，则每次更新反向映射元数据时，如，在缓存中插入新的更新请求或者删除旧的更新请求，缓存中更新请求的存储位置均会重新调整，造成一定的时延，由于反向映射元数据的数据量大，则在缓存中存储反向映射元数据会占用大量内存。

本发明实施例中，根据回收进程的工作状态，判断是否在所述缓存中更新所述反向映射元数据，提供不在缓存中更新反向映射元数据的方案，在回收进程启动之前，从系统日志中已存储的更新请求提取出反向映射元数据，且合并至SAN上，以保证反向映射元数据的完整性。由于反向映射元数据更新频繁，但是基本仅在回收进程中使用，因此，本发明实施例对于多数更新反向映射元数据的过程可以减少时延，提高更新效率，并且占用较少内存。

另外，在相关技术中，对于缓存已满的情况，服务器将SAN中原有的大量反向映射元数据与缓存中的反向映射元数据合并，将合并后的反向映射元数据重新写入SAN，由于缓存中的反向映射元数据远少于SAN中的反向映射元数据，导致实际写入SAN的反向映射元数据远大于需要写入的反向映射元数据，造成了严重的写入放大的问题。

本发明实施例在缓存已满时，无需将缓存中的反向映射元数据合并至SAN，不存在由缓存所导致的写入放大问题。而且，本发明实施例提供释放缓存空间的策略，以留出缓存的存储资源，提高缓存的利用率，进一步提高服务器的读写效率。需要说明的是，虽然系统日志满时，服务器将系统日志中的反向映射元数据合并至SAN，但是由于系统日志存储空间很大，因此合并时实际写入SAN的反向映射元数据与需要写入的反向映射元数据并不会相差很多，相比现有技术很大程度上弱化了写入放大的问题。

另外，本发明实施例支持反向映射元数据的更新过程与回收进程并发进行，提高了服务器的并发处理能力；而且，回收进程支持多个存储区域同时进行回收，增加了回收效率，也不会延迟反向映射元数据的更新效率。

本发明实施例支持上述实施例的更新过程与回收进程同时进行。为了更具体地体现本发明实施例所示的更新过程为回收进程带来的影响，本发明实施例以回收进程这一侧展开说明。图4是本发明实施例提供的一种回收方法流程图。参见图4，该实施例应用于服务器，且基于图3所示实施例以SAN作为指定存储区域为例进行说明，具体步骤包括：

400、回收进程启动之前，服务器将系统日志中所存储的更新请求合并至存储区域网络SAN中的反向映射元数据。

该步骤在图3所示实施例的步骤307已做出说明，不再赘述。

401、当启动回收进程时，服务器读取回收列表，回收列表用于指示回收进程所要回收的存储区域。

需要说明的是，回收列表是指示所要回收的存储区域的一种方式，在图3所示实施例的步骤304已做出说明。事实上，每次所要回收的存储区域也可以是以地址段的方式记录于服务器中，使得服务器每次对该次地址段范围内的存储区域进行回收。

402、基于回收列表，服务器读取SAN及缓存中的反向映射元数据。

基于图3所示实施例可知，反向映射元数据可能存储于SAN上，也可能在回收进程进行时存储于缓存中，因此，为了所读取的反向映射元数据更全面，回收的准确性更高，服务器读取SAN及缓存中所有的反向映射元数据。

在该步骤中，服务器从回收列表中确定所要回收的存储区域。在缓存中，对应同一个PLBA的更新请求在缓存中有序存储，则服务器查询对应于这些存储区域内的PLBA的更新请求，再从所查询的更新请求中提取出反向映射元数据、删除标识或者添加标识。在SAN中，对应同一个PLBA的反向映射元数据有序存储，服务器直接读取属于这些存储区域内的PLBA的反向映射元数据。

403、服务器合并所读取的反向映射元数据。

基于上述步骤402，进一步地，服务器将从SAN及缓存中所读取的反向映射元数据进行合并，如果存在两个相同的反向映射元数据，且一个反向映射元数据具有删除标识，另一个具有添加标识，则服务器确定不存在该反向映射元数据，从而可能回收该反向映射元数据对应的存储区域；如果一个反向映射元数据与其他反向映射元数据均不同，则服务器确定不回收反向映射元数据对应的存储区域。

404、服务器将合并后的反向映射元数据对应的存储区域内的数据块复制到第三存储区域，第三存储区域是指不在回收列表中的存储区域。

当然，本发明实施例对第三存储区域不做具体限定。例如，如果第一存储区域是指逻辑单元号为LUN1的存储区域，则第三存储区域可以是逻辑单元号为LUN2的存储区域。

本发明实施例中，回收进程是针对于所要回收的存储区域进行。当然，存在一种情况：所要回收的存储区域的数据块仍然被引用，也即是，存在反向映射元数据指向的PLBA位于所要回收的存储区域内。因此，在回收这些存储区域时，将合并后的反向映射元数据对应的存储区域内的数据块复制到第三存储区域，避免这些数据块被误删。

405、基于合并后的反向映射元数据，服务器将VLBA所指向的PLBA修改为第三存储区域的PLBA，并触发反向映射元数据的更新过程。

当然，将数据块复制到第三存储区域后，为了使得合并后的反向映射元数据中的VLBA还能引用该数据块，要将VLBA原来指向的PLBA修改为第三存储区域的PLBA，此时，会触发反向映射元数据的更新过程，即添加新的反向映射元数据(第三存储区域内的PLBA指向VLBA)，并将原来的反向映射元数据(第一存储区域内的PLBA指向VLBA)删除。由于该更新过程是在回收进程中，则根据图3所示实施例，服务器将具有删除标识的更新请求添加到缓存中。

406、服务器回收该回收列表中不具有指定标记且不具有反向映射元数据的存储区域。

基于上述步骤405的更新过程，为了确定当前所要回收的存储区域上的数据块已经不再被任何VLBA引用，则服务器再次读取缓存及SAN中的反向映射元数据，且进行合并，也即是，从缓存中读取到的具有删除标识的反向映射元数据、以及从SAN读取到的反向映射元数据进行合并，合并结果为不存在该反向映射元数据。此时，服务器可以对回收列表中不具有反向映射元数据的存储区域进行回收。

当然，为了释放缓存空间，留出缓存的存储资源，每次回收进程完成对任一存储区域的回收时，删除缓存中对应任一存储区域的反向映射元数据。

然而，考虑到图3所示实施例，在回收进程与反向映射元数据的更新同时进行时，存在以下两种情况：

第一种情况、如果更新请求指示添加反向映射元数据。

在该情况中，以回收进程是否完成从缓存及SAN中读取对应第一存储区域的反向映射元数据的过程作为时间点，如果未完成，则服务器在本次回收进程中可以从缓存中读取到反向映射元数据，并进行以上回收步骤；如果已完成，则第一存储区域被添加了指定标记。

在服务器已完成上述读取的过程后，所添加的反向映射元数据不会在回收进程被读取到，该反向映射元数据中的VLBA仍然引用第一存储区域的上的数据块，因此，在本步骤中，为了使得VLBA能正常引用第一存储区域上的数据块，服务器不会回收具有指定标记的第一存储区域。

第二种情况、如果更新请求指示删除反向映射元数据。

此时，第一存储区域的数据块已被复制到第三存储区域，如果更新请求指示删除反向映射元数据，则说明该反向映射元数据中的VLBA不再引用第一存储区域中的数据块，则服务器可以删除这些数据块，回收第一存储区域。

除以上两种情况，如果确定更新反向映射元数据的过程中没有进行回收进程，则回收列表中的存储区域也不会具有指定标记，此时，服务器已经完成复制数据块到第三存储区域、将VLBA原来指向的PLBA修改为第三存储区域的PLBA、添加新的PLBA指向VLBA的反向映射元数据、以及删除原来的PLBA指向VLBA的反向映射元数据。因此，服务器对回收列表中的存储区域逐一进行回收，即删除回收列表中不具有反向映射元数据的存储区域上的数据块，从而留出存储资源，提高SAN的利用率。

需要说明的是，当本次回收进程结束时，删除指定标记及缓存中所有的反向映射元数据，使得原来具有指定标记的存储区域可以在之后的回收进程中被回收，并释放缓存空间，提高缓存的利用率。

本发明实施例基于图3所示实施例以回收进程这一侧进行说明，与其并发进行的更新过程同样具备图3所示实施例的有益效果。尤其是，本发明实施例提高了服务器的并发处理能力；而且，回收进程支持多个存储区域同时进行回收，增加了回收效率，也不会延迟反向映射元数据的更新效率。

图5是本发明实施例提供的一种更新反向映射元数据的装置结构示意图。参见图5，该装置具体包括：

接收模块501，用于执行上述步骤301所涉及的过程。

存储模块502，用于执行上述步骤302所涉及的过程。

判断模块503，用于执行上述步骤303至步骤306所涉及的过程。

更新模块504，用于执行上述步骤307所涉及的过程。

相关技术中，由于对应同一个PLBA的更新请求在缓存中有序存储，则每次更新反向映射元数据时，如，在缓存中插入新的更新请求或者删除旧的更新请求，缓存中更新请求的存储位置均会重新调整，造成一定的时延，导致更新效率低，由于反向映射元数据的数据量大，则在缓存中存储反向映射元数据会占用大量内存。

本发明实施例中，根据回收进程的工作状态，判断是否在所述缓存中更新所述反向映射元数据，提供不在缓存中更新反向映射元数据的装置，在回收进程启动之前，从系统日志中已存储的更新请求提取出反向映射元数据，且合并至指定存储区域上，以保证反向映射元数据的完整性。由于反向映射元数据更新频繁，但是基本仅在回收进程中使用，因此，本发明实施例对于多数更新反向映射元数据的过程可以减少时延，提高更新效率，且占用较少内存。

需要说明的是：上述实施例提供的更新反向映射元数据的装置在更新反向映射元数据时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的更新反向映射元数据的装置与更新反向映射元数据的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。