TFS扩展块的优化方案
TFS目前使用扩展块来解决文件写、更新问题。扩展块的数量由磁盘可用空间、主块大小、扩展块大小、Dataserver(DS)配置项block_ratio决定。TFS主块和扩展块的数量在文件系统格式化的时候就已经确定，并且预先分配了所有块的存储空间。DS周期性的汇报存储空间使用率给Namserver，DS根据主块和扩展块使用率中的较大值做为DS储存空间的使用率。
扩展块使用率引发的问题
- 理想情况；扩展块与主块的使用率非常接近或相同；
- 扩展块使用率远低于主块的使用率：该趋势的持续大量扩展块空间的浪费。
- 扩展块使用率远高于主块的使用率：DS在计算可用空间时会导致以扩展块的使用情况为准，该趋势的持续会导致大量主块空间的浪费。这时DS即使有很多的剩余空间NS也认为DS已满，从而不能继续写数据到该DS。（扩展块配置得很小、且NS端的max_block_size配置得较大时会产生着这种情况）。
为什么需要扩展块？
- NS在分配block时，会考虑block是否已经满（超过阈值）；而NS收集到的block使用情况不是实时的（在心跳包中附带，周期性更新）；NS分配给客户端的block可能在客户端连接DS进行写操作时已经写满；DS要在NS分配的block上满足写请求，则需扩展块的空间（tfs文件名的特性导致，写必须在该block内完成）。
- 客户端一次open、多次write、在close的操作序列也导致在open分配块时，不能决定一个块剩余的长度是否足够。
- 保持文件名不变的更新语义使得更新操作必须在原来的块上得到满足，如果更新的文件长度比文件原来的长度要大，而原来的块又没有足够的空间时，则需要使用扩展块。
扩展块问题使得TFS数据服务器上的存储空间的利用率降低，解决扩展块问题有如下两种思路：
- 彻底摒弃扩展块：任意块都是对等的，当块满时，文件可以存储到任意块上；
- 将主块当扩展块使用：把主块拆分成多个扩展块使用。
方案1的实现思路
采用类似linux软链接文件的方式，当写或者更新某个文件，但NS分配的block A存储空间不足时，则将该文件存储在其他任意block B上，并对应的B上文件的<blockid、fileid>信息存储在block A上作为文件的内容，并标记该文件为一个链接文件；当读到这样的文件时，则先读出其内容解析出<blockid、fileid>，并读出文件的实际数据并返回给客户端。由于存在block迁移的情况发生，故链接文件的目标需为logic block id，这样即使block迁移走了文件数据仍能被读取到；而如果存physical block id，则当该block迁移走时，不能读到文件数据。
链接文件方案彻底摒弃扩展块的使用，不存在存储空间浪费的问题；当读取到链接文件时，需要从链接目标块间接读取一次（开销与目前扩展块方案差不多），但如果目标块已经迁移到其他的DS上时，则读取文件的开销就会提升（连NS获取block所在DS信息，从DS读取文件数据）。当块剩余的空间低于平均文件大小时，可能会在块的末尾出现很多链接文件，因为很多写存储空间都不够，导致使用链接文件。
方案2的实现思路
把所有的存储空间都格式化为主块，当需要扩展块时，可分配一个主块，并将其拆分为多个扩展块（这里为了简化实现，可直接固定扩展块的大小，影响不大），选择其中一个扩展块使用，当其他的块需要扩展块时，可继续从这个块里分配，直到拆出来的所有扩展块都被用掉，则分配下一个主块，继续拆分。
这个方案有效的解决了存储空间浪费的问题，因扩展块是按需分配，而不是预先分配好的，无论扩展块与主块的使用比率如何，都可以用到把空间用完为止（需考虑为文件更新预留一些存储空间）。
飞哥提出的方案3
总体思路与方案2类似，但扩展块的使用并不划分为固定大小的单元，而是需要多少分配多少；文件不会垮块存储，当主块空间不足时，所有的文件数据都写到扩展块上，索引项增加文件所在的block编号。
存在的问题
- 如果更新很多，会导致块上很多文件存储在扩展块中(一个块的元数据增多)，在压缩、复制需要读取的block数增多（随机IO）。
- 主块上剩余的空间被浪费，浪费的空间由最后一次写操作的大小决定。
在TFS固定块大小加更新支持的基础上，扩展块是一个被逼出来的选择，关键问题是扩展块是大小固定（方案2）、还是可变大小（方案3），固定大小块的管理起来比较简单、但如果使用一部分之后，一直没有更新，则块后面的空间就会浪费掉；可变大小的块（每个块对应一个文件的数据），则需要更多的元数据来管理（更大的index文件，更长的块链），同时也存在存储空间浪费的情况；个人觉得方案2是个不错的选择，是考虑效率和管理成本之间的一个折中方案。
