英文原文： 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”， 

操作分为三种类型：

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

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

  • 文件操作 – 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