WatchStor观察:文件系统管理遭遇“困境”

存储 容灾备份
POSIX文件系统界面并不适用于今天的数据管理任务,这就导致用户花费大量成本来解决像数据完整性和法规遵从这样的问题。

【WatchStor独家译文】文件管理的问题实际是:这些文件并不是被作为文件来管理的,而是作为信息被管理的。标准POSIX信息要基础得多。像Google Desktop这样的应用可以帮助你找到你想要的,但是这只能解决一部分问题。

现在几乎大多数人使用的文件系统界面都是POSIX。我们希望文件系统支持的界面是open()系统调用,或者如果使用C Library Interface,希望支持的是fopen()调用。现在,我们需求很多其他信息用于数据追踪、备份和归档、用户元数据和文件可靠性,还有其他很多很多。

事实是,数据存储厂商在用户方面解决所有这些问题,而不是作为标准的一部分。一些SNIA成员推行XAM,但这只是树梢,文件系统集成问题仍然不够明确。到底是cp还ftp来传输XAM信息?

现在我们需要的是行业范围内的讨论,或者一个组织(或者多个组织)来带头解决这个问题。让众多厂商来开一个SNIA大会并不能从根本上解决我们目前面临的两难境地。我们需要定义覆盖一份文件或者一套文件的普遍特性或者一项所有人都支持的标准架构来实现数据管理的标准化。我曾经看到我的用户反反复复做着同一件事,针对文件定义用户级元数据、备份和归档策略,将一小部分资金用于满足数据库或者其他软件架构方面的这些需求,结果发现仍然是不具备便携性的,而且永远也不会实现。其中大多数工作都是保存归档,这对保存信息有特殊的要求。

现在POSIX提供了什么?

现在POSIX包括了关于每份文件访问时间、创建使用、用户、部门和权限等信息,这就是POSIX提供的信息范围。所有这些都是通过stat() system call提供的。从基本上来说,POSIX定义了使用getattr()和setattr()系统调用的特性。这是扩展文件系统的标准方法。

问题是,没有统一的一套特性可以覆盖所有文件系统。举个例子,一家厂商希望支持HSM界面,HSM使用的是一种被称为DMAPI的通用架构。这家厂商可能会采用POSIX扩展特性来部署DMAPI,或者将DMAPI作为这些扩展特性的一部分。当文件系统不能打开文件的话,文件系统就会检查扩展特性,发现这份文件是处于HSM控制下的。如果你将这份文件复制到另一个文件系统或者另一个不同的操作系统下会发生什么?如果你正在使用的是像cp这样的标准拷贝命令,或者通过ftp上传文件,那么所有关于这份文件以及扩展特性的信息都会丢失。

以下是标准stat()调用的一些变量:

·上一次访问时间
·文件系统I/O的块大小
·分配块的数量
·上一次变更的时间
·所有者的组ID
·文件保护模式
·上一次修改的时间
·固网数量
·总容量大小
·所有者的用户ID

这些信息对于在生命周期内管理文件来说是不够的。不管这是不是你的内部计划,一张三年前创建、需要保留30年的数字图片,甚至需要保留的纳税记录,这些信息并不足以帮助你追踪和保留文件。想象一下,你怎么面对数十亿甚至是数百亿的业务记录、医疗记录、政府记录、科研数据或者其他重要信息?这些文件通常是数据库等应用进行管理的,但是这并不是最理想的方法。

一个有关POSIX的建议

POSIX提供的一份文件相关信息是非常有限的,而且需要不时更新。作为标准POSIX文件的一部分,你应该在一份文件内提供以下信息:

·T10 Data Integrity Field (DIF)支持:目前,一个应用无法以标准方面满足DIF关于应用的规定
·例如SHA256这样的文件检验和:这对很多保存归档来说非常重要,它可以检验文件的完整性,现在很多企业都要求采用这一技术来确保数据完整性
·用户或者应用保存的文件元数据:例如创建文件的是哪一个应用版本
·标准化备份和HSM界面信息:应该备份这份文件吗?HSM应该保留几个副本?
·数据起源:这对文件监管链的完整性是很重要的

以上这些只是我认为一份在设备之间迁移的文件的一部分标准信息。如果没有关于文件的这些信息,我们可能要付出沉重代价,正如我们向厂商支付费用来写入用户空间应用在Unix系统上追踪这些信息。有趣的是,IBM大型主机用户嘲笑我们,因为MVS具有这项功能已经很多年了。我会采用POSIX标准特性和针对每种特性创建特性组来实现这一点。这就让我们在不影响主系统的同时获得这些功能。必须增加一些命令来组织这些特性,然后进行迁移,所有这些并不难。

变化的障碍

那么为什么现在还没有一个人这么做呢?我认为有以下几个原因:

·厂商不希望做任何变化,任何对POSIX的变更都可能需要在文件系统和操作系统方面作出更改
·厂商就是通过用户空间来盈利的。这是一个很糟糕的原因,但是我认为这是确实存在的。如果实现标准化了,你就不会再去购买它了
·这些变更可能会带来更多开销,你必须为分布数据准备额外的空间。这就增加了文件系统元数据需要的空间,增加打开和读取文件的时间

我不认为其中任何一个理由是“按兵不动”的好理由。厂商一直对系统做修改,所以第一个理由是说不通的。厂商可以从多种渠道盈利,所以这也不能说是一个障碍。额外的开销似乎也说不通,因为大多数文件都很大,相比之下元数据空间很小,读取512B字节的时间相比读取1024字节的时间来说是非常微小的。

阻碍变更的最后一个障碍就是,标准并不覆盖用户方面,而是厂商来控制的。在我看来,要想有所变化的唯一希望就要寄托于那些在用户空间应用方面花费大量资金的用户,比如政府机构和工业用户。他们应该参与其中。【WatchStor独家译稿,未经许可禁止转载。合作伙伴请注明原作者及出处为WatchStor.com】

责任编辑:刘强 来源: Watchstor编译
相关推荐

2009-10-12 11:14:51

LinuxLinux磁盘文件系统管理

2010-04-07 18:42:42

Unix命令

2009-10-13 14:31:26

:Linux系统磁盘系统管理

2017-08-17 10:03:06

磁盘系统实例

2010-08-10 09:13:52

Unix系统管理员Ubuntu

2010-01-14 17:05:42

MySQL CentO

2009-02-03 13:11:09

冰岛绿色IT数据中心

2010-05-05 15:56:37

Unix系统

2011-09-01 13:42:15

优化布线系统管理布线系统

2010-05-05 16:27:22

Unix系统

2010-05-04 15:22:25

Unix系统

2011-08-17 09:33:45

数据中心系统管理虚拟化

2013-05-02 14:06:30

Android开发用户系统管理

2017-03-27 09:30:14

Linux系统管理技巧

2013-05-09 09:27:46

2011-11-17 16:06:45

IT系统管理

2012-02-29 00:57:41

Linux系统

2012-07-31 14:57:14

NetGain EM

2009-07-11 16:04:04

布线系统管理优化

2015-04-22 13:25:43

点赞
收藏

51CTO技术栈公众号