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