SAS300G×6的磁盘我们使用了一段时间，相对比较稳定，这让我们有信心使用更大容量的节点而不会过于担心服务器失效带来的数据迁移对系统性能的影响，当前TFS主要的机型使用SAS300G×12的磁盘配置。
随着淘宝网前端的CDN越来越高效、稳定，到达TFS的请求流量也更加平缓，这让我们有可能对单个节点的服务能力做出更加可靠的规划，也可以使用更加廉价的存储设备，未来我们的主要存储节点将使用1TSATA×12甚至更大的磁盘设备，进一步降低成本。InfoQ：TFS的应用规模达到数百台PC server和PB级数据量，其扩展性如何？架构上是如何保证的？
在TFS中我们将大量的小文件合并成为一个大文件，类似GFS中Chunk的概念，而Chunk的定位信息我们称之为一级索引，而chunk内部具体的文件定位信息我们称之为二级索引，同时在TFS文件名称中包含这些索引信息，在用户写入一个文件之前，他必须向TFS系统申请一个文件名称。这种方式虽然在某些情况下显得不像传统文件系统那样灵活，但也给了我们系统更大的可扩展性。我们保证可以中心控制节点的内存可以支撑PB级别的一级索引，而二级索引仅需要针对单台数据量。这样，我们就避免了数据量膨胀带来的扩容难度。当存储容量出现不足，我们需要进行系统扩容的时候，可以根据数据增长情况进行规划，任意数量的加入提供相应存储的服务器。而这些新的存储服务器会向中心控制节点进行报告。而中心控制节点在有数据写入时，将根据已存储容量的百分比、系统当前负载等参数动态地分配写入的服务器。同时，在系统空闲时间段，中心控制节点也会根据当前的数据分布情况制定数据迁移计划，并逐步完成数据平衡。与此类似，当发生服务器崩溃时，中心控制节点也会进行数据迁移以保证足够的备份，同时也会进行数据均衡操作。这些操作都是自动进行的，不需要人工干预。
这种方式在1000台以内的集群基本上能够工作良好，如果集群规模更大，中心控制节点可能会出现一些性能瓶颈，届时我们可以使用一个分布式集群来解决，相应已经比较成熟的技术方案现在已经比较多了。InfoQ:您在介绍TFS的特点时，多次提到“性能”这个关键词，请问对于一个文件系统来说，性能一般应该考虑哪些因素？目前，提高文件系统性能的通用方法有哪些？
现在我们可以讨论一下TFS的性能考量的维度了。其实当前每个流行的分布式文件系统都有自己的侧重点，分别针对自己不同的应用场景。对于离线型的数据分析需求，由于数据总量巨大，底层分布式文件系统更加注重系统的整体吞吐率，为了适应当前流行的map_reduce模型，这一类的文件系统会将文件切成多份，分而治之。同时和上层的逻辑配合，采用大块顺序写入、读出的方式来提升性能，典型的代表就是Hadoop使用的HDFS。
实际提供线上服务的分布式文件系统中，也根据服务类型的不同而采用差异化的存储方式，例如针对音、视频等相对比较大的文件，可能采用和离线应用相同的方式将文件切片并发读写访问，从而达到更高的传输速度。由于相同容量下文件数量比较少，甚至有可能完全实现类似传统文件系统的目录、权限等功能，而不会受到inode的限制。如果面临淘宝相同的海量小文件存储，这种方式就完全无法提供性能的支持了，inode数量的膨胀会很快吃掉大量的昂贵内存，如果要平衡成本将部分inode放入磁盘，面对基本上完全随机、没有热点的访问又无法保证寻址的效率，我们只能通过减少元数据的方式来解决这个问题。
为什么说我们的TFS面临着完全随机、基本上没有热点的数据访问？在淘宝的数据部署中，TFS前端有两层更加靠近用户的缓存系统来保证用户展示页面的速度，最终到达TFS的请求大概只有总请求数量的2%左右，随着前端缓冲的效率不断提升，这个比例还会继续下降，我们可以想象一下是否仍然有热点数据存在。与此同时，淘宝网的业务特点决定了相对于读取请求，写入请求量不在一个数量级上，而修改操作量就更少，这就决定了我们使用进行随机修改、随机写入的方式来避免顺序写入不进行修改给随机读取带来的成本。