GlusterFS扩展属性

英文原文: http://hekafs.org/index.php/2011/04/glusterfs-extended-attributes/

 

天马行空的意译,对正确性负责,不一定全和准确。

 

扩展属性是现代文件系统普遍支持,而又不容易被用户发现的特性。

 

Glusterfs中DHT,AFT, stripe都广泛使用了扩展属性即xattr。

 

xattr是一个key-value结构, 包括一个字符串key, 和一个二进制的value。我们有get/set/list xattr方法来操作它们。

 

在glusterfs中广泛使用了这样一个小伎俩:  当set/get xattr的时候,会触发gluster server的相关操作。例如:DHT中的 reblance代码使用了一个特定的attr来触发重新计算DHT layout的操作。

 

下面着重讨论 DHT中的trusted.glusterfs.dht xattr和 AFR中的trusted.glusterfs.afr.* xattr

 

DHT功能的核心是一致性哈希(consistent hashing)。文件存放的地点取决于文件名的哈希值, 每个brick都有一个哈希值区间,文件名的哈希值的落在某brick的哈希值区间,文件就存放在该birck上。

 

而目录有点不一样,目录在每个brick上都有。但是每个目录的xattr trusted.glusterfs.dht都不一样。因为它们所具有的哈希区间不同。

 

当lookup目录的时候,我们需要收集这些xattr, 组成一个table。同时需要注意区间之间存在的空隙和重叠的问题。

 

不难发现,这种方法有严重的扩展性(scalability)问题, 每当添加/删除一个brick的时候,我们就要重新计算xattr中存放的哈希区间。

 

然而, AFR在使用attr方面,比DHT更加复杂。

比如一个叫test1的afr卷,由test1-client-0和test1-client-1两个brick组成。 那么test1-client-0上的文件就会具有名为 trusted.afr.test1-client-1的xattr.

 

这是因为AFR的目的就是为了从failure中恢复。所以在一个brick上的操作会在其他所有brick上的xattr中记录,这样当副本数目多余2个时候很浪费。:-/

 

在xattr中存放的是“等待操作的counter”, 

操作分为三种类型:

  • 数据操作�C mostly writes but also e.g. truncates

  • 元数据操作�C e.g. chmod/chown/chgrp, and xattrs (yes, this gets recursive)

  • 文件操作 �C create, delete, rename, etc.

 每次文件系统操作执行前,都会首先对counter加1。

执行完成后,再对counter 减一。

 

正常情况下,counter应该回到0。入如果有节点中途出了问题,counter不是0,那么我们就可以知道这个节点out of date, 并启动self-heal修复它。

 

那么可想而知,最严重的情况是 AFR两个副本节点的counter都不是0, 我们将这种特殊情况称为 "split brain"。 这时系统很难或者说几乎不可能自己恢复正常。


转自:http://glusterfs.iteye.com/blog/1823744


你可能感兴趣的:(GlusterFS,扩展属性)