GlusterFS扩展属性

cl_303303303

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