CN103514298A - 一种实现文件锁的方法及元数据服务器 - Google Patents

Abstract

本申请公开了一种实现文件锁的方法及元数据服务器，所述方法包括：元数据服务器接收请求方发送的请求消息，所述请求消息包括申请锁消息，其中携带有请求锁定的文件的编号和请求方的标识信息；所述元数据服务器根据所述编号获取所述文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；所述元数据服务器根据所述文件锁持有属性判断所述文件是否已加文件锁，如果已加文件锁，并且文件锁持有方不是所述请求方，则根据所述文件锁更新时间属性判断文件所加文件锁是否超时，如果超时，则将所述文件锁持有属性的属性值更新为所述请求方的标识信息，并将所述文件锁更新时间属性的属性值更新为当前时间。

Description

一种实现文件锁的方法及元数据服务器

技术领域

本发明涉及分布式文件***领域，尤其涉及一种实现文件锁的方法及元数据服务器。

背景技术

分布式文件***一般采用客户端/服务器架构（参考图1），数据保存在服务器上，而客户端的应用程序能够像访问本地文件***一样访问位于远程服务器上的文件。以时间为线索，可以将分布式文件***的发展历程分为三个阶段：1）网络文件***（1980s），2）共享存储（SAN）集群文件***（1990s），3）面向对象的并行文件***（2000s）。目前较有影响的分布式文件***有Google File System（GFS）、Lustre和HDFS等。

分布式文件***在云计算时代的重要作用日益凸显。在一个云计算环境中，分布式文件***至少可以应用在四个方向：1）作为海量存储后端支撑，向上通过各种协议（FTP、iSCSI或私有协议等）提供存储服务，用于存储/备份用户数据、虚拟机镜像文件等；2）融合计算和存储功能，用于大数据的存储与分析，支撑MapReduce作业；3）提供开放接口，使得第三方网站可以通过分布式文件***提供的存储服务为基础构建新的服务；4）作为用户传送文件或者服务商发布内容时的缓冲。

分布式文件***可以看作是对分布式存储资源的虚拟化，它将分散、异构的存储资源整合在一个命名空间之下，对上提供POSIX（Portable OperatingSystem Interface，可移植操作***接口），屏蔽分布式文件***内在的复杂机制。POSIX文件锁机制对于云计算和云存储具有重要的意义，很多传统应用依赖于POSIX文件锁才能正常运行，因此一个支持POSIX文件锁的分布式文件***可以更好的支撑上层应用的运行。同时分布式锁为虚拟机的健康运行提供了底层保障，可以有效避免虚拟机多实例的出现。

然而在分布式环境下，文件锁的管理要比单机文件***复杂的多，其困难之处不在于文件锁的创建，而在于文件锁的合理正常释放。分布式文件***面对的是跨节点的多个进程，每个进程或者节点都有可能突然崩溃而无法完成文件锁的正常释放，导致对应的数据/文件无法被其他进程/节点访问而继续提供服务。

发明内容

本发明要解决的技术问题是提供一种实现文件锁的方法及元数据服务器，能够在加文件锁的进程或节点崩溃后，正常释放文件锁。

为解决上述技术问题，本发明的一种实现文件锁的方法，应用于分布式文件***中，包括：

元数据服务器接收请求方发送的请求消息，所述请求消息包括申请锁消息，其中携带有请求锁定的文件的编号和请求方的标识信息；

所述元数据服务器根据所述编号获取所述文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性判断所述文件是否已加文件锁，如果已加文件锁，并且文件锁持有方不是所述请求方，则根据所述文件锁更新时间属性判断文件所加文件锁是否超时，如果超时，则将所述文件锁持有属性的属性值更新为所述请求方的标识信息，并将所述文件锁更新时间属性的属性值更新为当前时间。

进一步地，所述方法还包括：

所述元数据服务器如果判断所述文件未加文件锁，则将所述文件锁持有属性的属性值修改为所述请求方的标识信息，并将所述文件锁更新时间属性的属性值修改为当前时间。

进一步地，所述方法还包括：

所述元数据服务器如果判断所述文件已加文件锁，并且文件锁持有方是所述请求方，则将所述文件锁更新时间属性的属性值修改为当前时间。

进一步地，所述方法还包括：

所述请求消息还包括更新锁消息，其中携带有要更新文件锁的文件的编号和请求方的标识信息；

所述元数据服务器根据所述更新锁消息中携带的编号获取所述更新文件锁的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性如果判断所述要更新文件锁的文件已加文件锁，并且文件锁持有方是所述请求方，则将所述文件锁更新时间属性的属性值更新为当前时间。

进一步地，所述方法还包括：

所述请求消息还包括释放锁消息，其中携带有要释放文件锁的文件的编号和请求方的标识信息；

所述元数据服务器根据所述释放锁消息中携带的编号获取所述要释放文件锁的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性判断所述要释放文件锁的文件是否已加文件锁，如果已加文件锁，则判断文件锁持有方是否是所述请求方，如果是，则将所述文件锁持有属性的属性值修改为表示未加锁；如果不是，则返回禁止释放信息。

进一步地，所述方法还包括：

所述元数据服务器接收请求方发送的文件写请求，所述文件写请求中携带有要修改的文件的编号和请求方的标识信息；

所述元数据服务器根据所述文件写请求中携带的编号获取所述要修改的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性判断所述要修改的文件是否已加文件锁，如果已加文件锁，则判断文件锁持有方是否是所述请求方，如果是，则将所述文件锁更新时间属性的属性值更新为当前时间；如果不是，则返回禁止修改操作信息。

进一步地，所述方法还包括：

所述元数据服务器接收请求方发送的文件读取请求，所述文件读取请求中携带有要读取的文件的编号和请求方的标识信息；

所述元数据服务器根据所述文件读取请求中携带的编号获取所述要读取的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性如果判断所述要读取的文件已加文件锁，并且文件锁持有方是所述请求方，则将所述文件锁更新时间属性的属性值更新为当前时间。

进一步地，一种元数据服务器，应用于分布式文件***中，包括：接收单元、信息定位单元、判断单元和属性修改单元，其中：

所述接收单元，用于接收请求方发送的请求消息，所述请求消息包括申请锁消息，其中携带有请求锁定的文件的编号和请求方的标识信息；

所述信息定位单元，用于根据所述编号获取所述文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述判断单元，用于根据所述文件锁持有属性判断所述文件是否已加文件锁，如果已加文件锁，并且文件锁持有方不是所述请求方，则根据所述文件锁更新时间属性判断文件所加文件锁是否超时；

所述属性修改单元，用于在所述判断单元判断超时后，将所述文件锁持有属性的属性值更新为所述请求方的标识信息，并将所述文件锁更新时间属性的属性值更新为当前时间。

进一步地，所述属性修改单元，还用于在所述判断单元判断所述文件未加文件锁后，将所述文件锁持有属性的属性值修改为所述请求方的标识信息，并将所述文件锁更新时间属性的属性值修改为当前时间；在所述判断单元判断所述文件已加文件锁，并且文件锁持有方是所述请求方后，将所述文件锁更新时间属性的属性值修改为当前时间。

进一步地，所述接收单元，还用于接收请求方发送的文件写请求，所述文件写请求中携带有要修改的文件的编号和请求方的标识信息；

所述信息定位单元，还用于根据所述文件写请求中携带的编号获取所述要修改的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述判断单元，还用于根据所述文件锁持有属性判断所述要修改的文件是否已加文件锁，如果已加文件锁，则判断文件锁持有方是否是所述请求方；

所述属性修改单元，还用于在所述判断单元判断判断文件锁持有方是所述请求方后，将所述文件锁更新时间属性的属性值更新为当前时间；在判断文件锁持有方不是所述请求方后，返回禁止修改操作信息。

综上所述，本发明在分布式文件***中实现文件锁，能够在文件锁的持有方未正常释放文件锁即发生崩溃的情况下，实现文件锁的释放，使其他进程或节点能够对文件加文件锁，对文件进行修改等操作。

附图说明

图1是现有技术中的分布式文件***的架构图；

图2是本发明实施方式的实现文件锁的方法中申请锁的流程图；

图3是本发明实施方式的实现文件锁的方法中释放锁的流程图；

图4是本发明实施方式的实现文件锁的方法中更新锁的流程图；

图5是本发明实施方式的元数据服务器的架构图。

具体实施方式

本申请在分布式文件***中实现文件锁，解决分布式文件***中文件锁无法正常释放带来的问题，本申请中为文件描述信息扩展文件锁持有属性和文件锁更新时间属性，客户端与元数据服务器通过心跳更新文件锁更新时间属性，如果某个文件锁超时，则完成释放操作。

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，申请中的实施例及实施例中的特征可以相互任意组合。

1）数据结构支持。

在元数据服务器的数据结构上，为每个文件描述信息（以fsnode标识）扩展两个属性，文件锁持有属性（lockowner）和文件锁更新时间属性（locklastupdate），分别代表文件锁的持有方和最后更新时间戳。属性lockowner是由文件锁持有方生成的64位随机正整数，属性locklastupdate是64位的时间。

2）文件锁的处理逻辑。

以增加的属性为基础，可以在客户端和元数据服务器中增加三种操作，即AcquireLK(申请锁)、ReleaseLK（释放锁）和UpdateLK（更新锁）。文件锁的主要逻辑控制均在元数据服务器一端，下面重点说明元数据服务器的处理逻辑。

如图2所示，本申请的实现文件锁的方法中申请锁的过程，包括：

步骤201：元数据服务器接收请求方发送的请求消息，请求消息包括申请锁消息，申请锁消息中携带有请求锁定的文件的编号和请求方的标识信息；

步骤202：元数据服务器根据申请锁消息中携带的编号获取请求锁定的文件的文件描述信息，文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

步骤203：元数据服务器根据文件锁持有属性判断请求锁定的文件是否已加文件锁，如果已加文件锁，则执行步骤204；如果未加文件锁，则执行步骤207；

步骤204：元数据服务器判断文件锁持有方是不是发送申请锁消息的请求方，如果不是，则执行步骤205；如果是，执行步骤208；

步骤205：元数据服务器根据文件锁更新时间属性判断文件所加文件锁是否超时，如果超时，则执行步骤206；如果未超时，则执行步骤209；

元数据服务器通过将当前时间减去文件锁更新时间属性的属性值的差值结果与锁允许的最大超时时间（LOCK_TIMEOUT）进行比较判断文件所加文件锁是否超时，如果差值结果大于LOCK_TIMEOUT，则超时；如果差值结果小于LOCK_TIMEOUT，则不超时。

步骤206：元数据服务器将文件锁持有属性的属性值更新为请求方的标识信息，并将文件锁更新时间属性的属性值更新为当前时间，结束；

步骤207：元数据服务器将文件锁持有属性的属性值修改为请求方的标识信息，并将文件锁更新时间属性的属性值修改为当前时间，结束；

步骤208：元数据服务器将文件锁更新时间属性的属性值修改为当前时间，结束；

步骤209：元数据服务器拒绝请求方的请求，返回错误信息。

以下为申请锁的过程的伪代码，请参考。

AcquireLk(inode,owner){

//从inode定位到文件描述信息

fsnode=locate(inode);

if(fsnode-＞lockowner＜=0){

//当前文件未被加锁，因此可以允许对锁的申请

fsnode-＞lockowner=owner;

//设置最后更新时间为当前时间

fsnode-＞lastupdate=now();

}else{

if(fsnode-＞lockowner==owner){

//允许文件锁持有方重复加锁

fsnode-＞lastupdate=now();

}else{

//LOCK_TIMEOUT是***常数，即锁允许的最大超时时间

if(now()-(fsnode-＞lastupdate)＞LOCK_TIMEOUT){

//如果锁超时，则视为无效

fsnode-＞lockowner=owner;

fsnode-＞lastupdate=now();

}else{

//拒绝加锁

return ERROR_LOCKED;

}

}

}

return STATUS_OK;

}

如图3所示，本申请的实现文件锁的方法中释放锁的过程，包括：

步骤301：元数据服务器接收请求方发送的请求消息，请求消息包括释放锁消息，释放锁消息中携带有要释放文件锁的文件的编号和请求方的标识信息；

步骤302：元数据服务器根据释放锁消息中携带的编号获取要释放文件锁的文件的文件描述信息，文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

步骤303：元数据服务器根据文件锁持有属性判断要释放文件锁的文件是否已加文件锁，如果已加文件锁，则执行步骤304；如果未加文件锁，则执行步骤307；

步骤304：元数据服务器判断文件锁持有方是否是请求方，如果是，则执行步骤305；否则，执行步骤306；

步骤305：元数据服务器将文件锁持有属性的属性值修改为表示未加锁，结束；

步骤306：元数据服务器返回禁止释放信息，结束；

步骤307：元数据服务器返回状态正常信息，结束。

以下为释放锁的过程的伪代码，请参考。

ReleaseLK(inode,owner){

//从inode定位到文件描述信息结构

fsnode=locate(inode);

if(fsnode-＞lockowner＞0){

if(fsnode-＞lockowner==owner){

//正常释放锁

fsnode-＞lockowner=0;

fsnode-＞lastupdate=0;

}else{

//不允许进程释放其他进程的锁

return ERROR_EACCES;

}

}

return STATUS_OK;

}

如图4所示，本申请的实现文件锁的方法中更新锁的过程，包括：

步骤401：元数据服务器接收请求方发送的请求消息，请求消息包括更新锁消息，更新锁消息中携带有要更新文件锁的文件的编号和请求方的标识信息；

步骤402：元数据服务器根据更新锁消息中携带的编号获取更新文件锁的文件的文件描述信息，文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

步骤403：元数据服务器根据文件锁持有属性判断要更新文件锁的文件是否已加文件锁，并且文件锁持有方是否是请求方，如果是，则执行步骤404；如果文件未加锁或者文件已加锁但持有方不是请求方，则执行步骤405；

步骤404：元数据服务器将文件锁更新时间属性的属性值更新为当前时间，结束；

步骤405：元数据服务器返回错误信息。

以下为更新锁的过程的伪代码，请参考。

UpdateLK(inode,owner){

//从inode定位到文件描述信息结构

fsnode=locate(inode);

if(fsnode-＞lockowner＞0&&fsnode-＞lockowner==owner){

fsnode-＞locklastupdate=now();

}

return STATUS_OK;

}

客户端可以维持一个已经加文件锁的文件列表，周期性的更新加锁的文件的时间戳，一般来说，这个周期需要小于LOCK_TIMEOUT/2。

3）在读写过程中的应用。

增加了文件锁的处理逻辑以后，可以在读写过程中加入控制，以共同完成对分布式文件***的访问管理。分布式文件***的读写主要是对文件块的读写，处理过程如下。

下面对在读过程中加入的控制进行说明。

步骤a：元数据服务器接收请求方发送的文件读取请求，文件读取请求中携带有要读取的文件的编号和请求方的标识信息；

步骤b：元数据服务器根据文件读取请求中携带的编号获取要读取的文件的文件描述信息，文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

步骤c：元数据服务器根据文件锁持有属性判断要读取的文件是否已加文件锁，并且文件锁持有方是否是请求方，如果是，则执行步骤d；

步骤d：元数据服务器将文件锁更新时间属性的属性值更新为当前时间。

如果文件未加锁或者文件已加锁但持有方不是请求方，则不对文件锁更新时间属性进行更新，读取文件后结束。

以下为读过程的伪代码，请参考。

//省略其他无关参数

ReadChunk(inode,owner){

//从inode定位到文件描述信息结构

fsnode=locate(inode);

//每次读取则更新更新时间戳

if(fsnode-＞lockowner==owner&&fsnode-＞lockowner＞0){

fsnode-＞locklastupdate=now();

}

//省略读操作细节

}

下面对在写过程中加入的控制进行说明。

步骤A：元数据服务器接收请求方发送的文件写请求，文件写请求中携带有要修改的文件的编号和请求方的标识信息；

步骤B：元数据服务器根据文件写请求中携带的编号获取要修改的文件的文件描述信息，文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

步骤C：元数据服务器根据文件锁持有属性判断要修改的文件是否已加文件锁，如果已加文件锁，则执行步骤D；

如果未加文件锁则直接进行文件的写操作，修改文件。

步骤D：元数据服务器判断文件锁持有方是否是请求方，如果是，则执行步骤E；否则，执行步骤F；

步骤E：元数据服务器将文件锁更新时间属性的属性值更新为当前时间；

步骤F：元数据服务器返回禁止修改操作信息。

以下为读过程的伪代码，请参考。

//省略其他无关参数

WriteChunk(inode,owner){

//从inode定位到文件描述信息结构

fsnode=locate(inode);

if(fsnode-＞lockowner＞0&&owner＞0){

if(fsnode-＞lockowner==owner){

fsnode-＞locklastupdate=now();

}else{

//决绝访问

return ERROR_EACCESS;

}

}

//省略写操作细节

}

如图5所示，本申请还提供了一种元数据服务器，应用于分布式文件***中，包括：接收单元、信息定位单元、判断单元和属性修改单元，其中：

接收单元，用于接收请求方发送的请求消息，请求消息包括申请锁消息，其中携带有请求锁定的文件的编号和请求方的标识信息；

信息定位单元，用于根据编号获取文件的文件描述信息，文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

判断单元，用于根据文件锁持有属性判断文件是否已加文件锁，如果已加文件锁，并且文件锁持有方不是请求方，则根据文件锁更新时间属性判断文件所加文件锁是否超时；

属性修改单元，用于在判断单元判断超时后，将文件锁持有属性的属性值更新为请求方的标识信息，并将文件锁更新时间属性的属性值更新为当前时间。

属性修改单元，还用于在判断单元判断文件未加文件锁后，将文件锁持有属性的属性值修改为请求方的标识信息，并将文件锁更新时间属性的属性值修改为当前时间；在判断单元判断文件已加文件锁，并且文件锁持有方是请求方后，将文件锁更新时间属性的属性值修改为当前时间。

接收单元，还用于接收请求方发送的文件写请求，文件写请求中携带有要修改的文件的编号和请求方的标识信息；

信息定位单元，还用于根据文件写请求中携带的编号获取要修改的文件的文件描述信息，文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

判断单元，还用于根据文件锁持有属性判断要修改的文件是否已加文件锁，如果已加文件锁，则判断文件锁持有方是否是请求方；

属性修改单元，还用于在判断单元判断判断文件锁持有方是请求方后，将文件锁更新时间属性的属性值更新为当前时间；在判断文件锁持有方不是请求方后，返回禁止修改操作信息。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现，相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

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

Claims (10)

1.一种实现文件锁的方法，应用于分布式文件***中，包括：

元数据服务器接收请求方发送的请求消息，所述请求消息包括申请锁消息，其中携带有请求锁定的文件的编号和请求方的标识信息；

所述元数据服务器根据所述编号获取所述文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性判断所述文件是否已加文件锁，如果已加文件锁，并且文件锁持有方不是所述请求方，则根据所述文件锁更新时间属性判断文件所加文件锁是否超时，如果超时，则将所述文件锁持有属性的属性值更新为所述请求方的标识信息，并将所述文件锁更新时间属性的属性值更新为当前时间。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述元数据服务器如果判断所述文件未加文件锁，则将所述文件锁持有属性的属性值修改为所述请求方的标识信息，并将所述文件锁更新时间属性的属性值修改为当前时间。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述元数据服务器如果判断所述文件已加文件锁，并且文件锁持有方是所述请求方，则将所述文件锁更新时间属性的属性值修改为当前时间。

4.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述请求消息还包括更新锁消息，其中携带有要更新文件锁的文件的编号和请求方的标识信息；

所述元数据服务器根据所述更新锁消息中携带的编号获取所述更新文件锁的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性如果判断所述要更新文件锁的文件已加文件锁，并且文件锁持有方是所述请求方，则将所述文件锁更新时间属性的属性值更新为当前时间。

5.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述请求消息还包括释放锁消息，其中携带有要释放文件锁的文件的编号和请求方的标识信息；

所述元数据服务器根据所述释放锁消息中携带的编号获取所述要释放文件锁的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性判断所述要释放文件锁的文件是否已加文件锁，如果已加文件锁，则判断文件锁持有方是否是所述请求方，如果是，则将所述文件锁持有属性的属性值修改为表示未加锁；如果不是，则返回禁止释放信息。

6.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述元数据服务器接收请求方发送的文件写请求，所述文件写请求中携带有要修改的文件的编号和请求方的标识信息；

所述元数据服务器根据所述文件写请求中携带的编号获取所述要修改的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性判断所述要修改的文件是否已加文件锁，如果已加文件锁，则判断文件锁持有方是否是所述请求方，如果是，则将所述文件锁更新时间属性的属性值更新为当前时间；如果不是，则返回禁止修改操作信息。

7.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述元数据服务器接收请求方发送的文件读取请求，所述文件读取请求中携带有要读取的文件的编号和请求方的标识信息；

所述元数据服务器根据所述文件读取请求中携带的编号获取所述要读取的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述元数据服务器根据所述文件锁持有属性如果判断所述要读取的文件已加文件锁，并且文件锁持有方是所述请求方，则将所述文件锁更新时间属性的属性值更新为当前时间。

8.一种元数据服务器，应用于分布式文件***中，包括：接收单元、信息定位单元、判断单元和属性修改单元，其中：

所述接收单元，用于接收请求方发送的请求消息，所述请求消息包括申请锁消息，其中携带有请求锁定的文件的编号和请求方的标识信息；

所述信息定位单元，用于根据所述编号获取所述文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述判断单元，用于根据所述文件锁持有属性判断所述文件是否已加文件锁，如果已加文件锁，并且文件锁持有方不是所述请求方，则根据所述文件锁更新时间属性判断文件所加文件锁是否超时；

所述属性修改单元，用于在所述判断单元判断超时后，将所述文件锁持有属性的属性值更新为所述请求方的标识信息，并将所述文件锁更新时间属性的属性值更新为当前时间。

9.如权利要求8所述的元数据服务器，其特征在于：

所述属性修改单元，还用于在所述判断单元判断所述文件未加文件锁后，将所述文件锁持有属性的属性值修改为所述请求方的标识信息，并将所述文件锁更新时间属性的属性值修改为当前时间；在所述判断单元判断所述文件已加文件锁，并且文件锁持有方是所述请求方后，将所述文件锁更新时间属性的属性值修改为当前时间。

10.如权利要求8所述的元数据服务器，其特征在于：

所述接收单元，还用于接收请求方发送的文件写请求，所述文件写请求中携带有要修改的文件的编号和请求方的标识信息；

所述信息定位单元，还用于根据所述文件写请求中携带的编号获取所述要修改的文件的文件描述信息，所述文件描述信息中扩展有文件锁持有属性和文件锁更新时间属性；

所述判断单元，还用于根据所述文件锁持有属性判断所述要修改的文件是否已加文件锁，如果已加文件锁，则判断文件锁持有方是否是所述请求方；

所述属性修改单元，还用于在所述判断单元判断判断文件锁持有方是所述请求方后，将所述文件锁更新时间属性的属性值更新为当前时间；在判断文件锁持有方不是所述请求方后，返回禁止修改操作信息。

Images