文件锁支持方案
背景
为保证对同一文件元数据操作的正确性，需要将对元数据的操作串行化，所以需要文件锁的支持
方案
在NameServer中，设置一个FileLockManager，用来负责保证单个文件元数据操作的原子性，FileLockManager为每个正在进行元信息修改的文件或目录维护一个内存结构LockEntry，该结构中包含一个引用计数ref_和一个读写锁rw_lock_
-
加锁的整体过程为：为最后一级文件加写锁，前面所有目录加读锁。加锁时，从根目录开始，不断尝试对下级目录进行加锁。同时，加读写锁时，写锁优先，可以防止写目录操作的饥饿现象
-
在对某一级目录或文件进行加锁时，首先在
FileLockManager查找其对应的LockEntry， - 如果没有找到，则说明并没有其它线程对该条链路进行操作，则构造一个新的
LockEntry，将其引用计数加1，并对该LockEntry中的读写锁进行加锁 -
如果找到，则说明有其它线程正在对该条链路进行操作，则首先将其引用计数加1将其对应的
LockEntry引用计数加1，然后再去尝试加读锁或写锁，如果加锁不成功，则会被阻塞直到加锁成功 -
在对某一级目录或文件操作完成后，对锁进行释放时，需要按照加锁的相反顺序进行释放。释放时，先释放读写锁，然后将
LockEntry的引用计数减1，如果引用计数减至0，则触发LockEntry的析构
rename时预防死锁
由于在rename时涉及到两个不同的路径，为防止死锁，rename操作时，都遵循按照路径的字典序进行加锁
可能需要的优化
- 考虑到每个文件的锁相对比较独立，可以对
FileLockManager中的映射信息进行分桶 - 绝大部分情况下，并不会出现同时操作同一个文件的元数据的情况，因此次加锁、释放锁的时候，会造成
LockEntry结构的构造和析构，或者可以辅以cache，将需要释放的LockEntry先缓存起来，让缓存去负责最终释放，当需要新申请LockEntry时，直接从缓存中召回一个即可，类似内核中slab的做法