PCCIFS锁定机制和UNIXNFS锁定机制之间的差异。本节将探讨SAN共享数据环境中的锁定问题。SAN网络中的锁定问题，为管理端用户的各种应用带来了新的挑战。另外，本节还将涉及客户端之间的语义差异问题。锁定和语义问题的结合，很可能会影响到用户如何更好地适应一个数据共享系统。

 

网络存储的锁管理

几乎所有的商业文件和数据库系统都能提供一定级别的锁定机制。锁定也是一种进程，用于保留访问或更新正在被一个用户/应用使用的数据。它的基本思想是：当一个用户正在使用某些数据时，阻止其他用户访问或更新该数据。

锁定机制的提供者称为锁管理器，它负责管理对锁定数据的访问，以及回应对锁定数据提出的访问请求。例如，当用户或应用需要访问锁定数据时，锁管理器给出警告，提醒用户或应用他们需要访问的数据已经锁定。如果不再锁定，数据随后可以更新。在这种情况下，锁管理器可以通知其他已打开该文件的用户，数据已被更新，建议他们重载数据。

 

数据库系统的锁管理器可以提供下面几种级别的锁定：

 

表级：一次只允许一个应用更新一个表。

记录级：锁定正在被一个应用使用的记录，其他应用可以访问表中的其他记录。

字段级：只锁定正在被使用的字段，记录中的其他字段或其他记录都可以被其他应用访问。同样，文件系统的锁管理器也可以提供下面几种锁定：

目录级：只允许一个应用更新一个目录中的所有文件。

文件级：只允许一个应用更新某个文件。

字节级：锁定一个文件中的某个字节范围。

 

1.锁管理器的透明性

 

文件系统和数据库使用锁定技术已经有好多年了，大致来说，它们都工作得很好，使多任务系统能够运行多个应用访问同一数据。对于许多用户来说，锁定是完全不可见的；而对另外一些用户来说，它是每天都会发生的事。不过，在SAN中锁定共享数据，很可能会给端用户带来一些新的问题。我们假定本章中所讨论的数据共享环境下的锁定机制都是文件级以下的，即不适用于目录级或文件级锁定。

通常，在引入一门新技术时，当用户使用它的功能时感觉越“透明”越好。换而言之，我们需要使用到新功能，但是不愿意改变已有的工作方式。令人遗憾的是，由于多客户环境下锁定数据的影响，上述需求对于数据共享技术来说，是不太容易满足的。

用于数据共享环境的锁管理器，可以基于多项信息的评定制订锁定的多级方案，如用户简要特征、优先权或策略以及像先来先锁定这样的访问数据顺序。制定如何向客户分配锁的方案，并不是一件无关紧要的事。用户不一定习惯弄清他们正在使用的文件中有哪些段落或单元格不能修改。

而且，他们也不习惯于收到这样的通知：他们正在使用的一个文件已经被更新，需要重新刷新它。如果要发送锁定消息，怎样通知用户？而用户又会如何反应？如果他们没有接到通知，他们就可能认为设备或网络出了问题；如果他们接收到了通知，又可能不知道该怎么办，可能会采取不合适的行动，如保存一个新的文件版本。因此，如何通知用户加锁/解锁的情况，确实是一件为难的事情。如果在用户试图写数据时，通知他该数据被临时锁定，那锁管理器是否应该告诉他该锁定何时解除？如果告诉他解除的时间，那又怎么样才能识别出是哪一个具体的锁已被解除了？上司是否应该能忽略下属用户加的锁？如果应该，又如何做到？如果做到这样，又怎么才能避免来自黑客或其他可能的威胁？

这些类型的问题很可能成为实现共享数据系统的最大威胁。除了技术上的可行性外，最大的挑战将来自用户不愿意改变工作方式的习惯。

 

2.语义的集成

数据共享面临的另一个挑战是语义集成的问题。语义集成主要解决文件系统之间的差异，这种差异体现在不同系统的存储和I/O操作类型、用户界面字符集等之间的差异。例如，不同的网络操作系统之间在文件的命名、打开、锁定、删除、更新等方面存在差异。如果一个UNIX系统上的用户创建了一个在Macintosh系统上非法的文件名，那么Macintosh上的用户如何才能使用该文件呢？

除了命名问题，还存在着另外一个问题，即一种功能可能被某个文件系统支持却不能被另一个文件系统支持。很多时候，两个系统以不同的方式实现同一功能。因此，考虑到同一或相似的功能可能具有不同的行为,在一个实现方案中很难面面俱到。问题不在于一个功能是如何实现的，而在于这种功能如何表现在同一时间里的不同平台中的不同用户面前。在最近几年里，语义集成是各个数据共享系统和应用致力于解决的一个重要问题，它将决定这些产品之间的差异。