写操作落在维护块上可能造成文件重名

[huaizong]

https://github.com/alibaba/tfs/blob/master/src/nameserver/client_request_server.cpp#L120-121

write 的open 模式，只考虑block_id > 0 的情况， 新插入的写操作block_id ＝＝0 ， 但是也需要规避写在正进行维护的逻辑块

          if ((block_id > 0)
              && (!(mode & T_NOLEASE)))

若压测场景中若正在写入的块处于压缩阶段，压缩后的块的索引seq值有一定概率没有更新，(seq 更新到旧的块上，新块的seq已经拷贝完成), 这带来的问题是下一次这个块上的产生的fileid重复，造成文件名重名。

[wangruowr]

你好。谢谢你的问题 1，首先处于压缩的，默认是已经被删除的。TFS认为文件名已经drop掉了 2，对于DS alive的情况，fileid是递增的，不会出现重复id的情况

[huaizong]

》 2，对于DS alive的情况，fileid是递增的，不会出现重复id的情况

问题点在块压缩期间，ns 发起压缩块 和 ns 分配写请求的如果是同一个块，因为压缩操作有时间窗口，这个窗口内，seq 更新到旧的块上，新块的seq已经拷贝完成， 这样带来的问题是，压缩后的块seq 没有更新，那新的 fileid 基于seq 递增仍然会产生重复的fileid

同样的诸如 均衡发起的块迁移操作也有类似问题